PLC features wish list

I have never had a look at Beckhoff - we never really see them in Ozz to be honest.

I know I have never seen one here but that does not mean they are not around.

There is quite a lot of Wago about but there are also a lot of problem reports - apart from earthing issues, not sure what or why but there is a reluctance to use them I have heard.
 
Oh no! Yet another wish list!

Cheap Ethernet is exactly that and you get what you pay for if you are lucky. Communications take processing power. Lots of it. So you can get cheap Ethernet without a processor or get an Ethernet card that has a processor dedicated to the Ethernet.

I would love to see a way to upload/download SQL database information over ethernet without using additional hardware/software.
Are you asking to download a SQL database into a PLC? If so this idea is nuts. I don't know of any current PLCs that have a SQL data base to upload. That would require a lot of bandwidth while transferring data let a lone the memory requirements on the PLC.

. 64 bit floating point math has been being done for years on 16 bit and 32 bit processors, the methods are well established. If its not there its either because the PLC maker believes it is not necessary or is just to lazy to be bothered, or probably more likely, justifies the latter by saying the former. Any PLC with a 32 bit processor really should support it. Granted it won't matter for 95% of the users, but it will make a big difference for the 5%.
Unless the PLC has a floating point FPU it will be expensive in processing time. Changing the firmware is easy. How many HMIs can upload 64 bit reals ( double ). It is the interface that gets tough.

Vista has been around for it seems like ever now and many manufacturers are just getting around to making the software Vista compatable. Why?? Others have been Vista compatable for 12-18 months or more.
The software developers get copies of new operating systems years before it is released to the public. Changing from XP to Vista took some effort because of the security road blocks. Hopefully it will not take as much effort to change to Windows 7. However, you should not blame the PLC manufacturers. They don't cause the turmoil. They would be happy to run on WinXP forever.

It isn't the PLC manufacturers software that is broken. It is the Vista you buy that isn't compatible.

I found that Vipa now has an Ethernet port on their Speed 7 processors that you can scan the network, (wireless or hardwired),with step 7. Step 7 finds the mac address and asks for an ip address with a subnet mask or you can allow your DHCP server to give it an address automatically.
Catching up. Automation Direct and Delta Computer Systems has been able to do that for many years now. Delta has a registered port that allows doing that over Ethernet. You plug in to the network and all the motion controllers show up. You just click on one and you are connected and IP address can be configured over Ethernet. Firmware can be downloaded over Ethernet too. That is a lot of code to have in the boot loader.

1. The ability to sync with NTP (network time protocol) servers. Seems like I'm forever fighting with clock drift and daylight savings time...
Getting accurate crystal cost money and even then they aren't perfect. Day light savings time is a self inflicted wound. Use zulu time or move to some state that doesn't have day light saving. Get your state to repeal day light savings time.

2. I wish that all Ethernet interfaces on PLCs would support plain old raw TCP for interfacing with standard networked applications.
What is a standard network application?

At some point most PLC's with an ethernet interface rely on TCP encapsulation, they should be able to transfer data this way, similar to the way data can be passed on a serial port.
Ah, so you want to transfer text and just use the Ethernet as a serial port. What does the serial port do with the data then? One can transfer binary data over serial ports too.

3. Enough memory to store comments and descriptors in the PLC.
Done, this is easy. We store comments for the steps and programs. The way we implemented this is to compress the whole project, which is in XML format, and download it into a special place in flash. It is kept separate from the binary image.

That, and I wish every PLC out there had a USB port -- wait... Not for programming, that should be Ethernet, but for having a simple place to plug in a standard thumbdrive, and upload/download a program without any need for software.
I'll second that USB port. USB has been around for twelve years now -
and legacy ports have been disappearing from laptops ever since - its about [expletive] time the PLC makers got on board.
Well which one do you guys want? I will let you to fight it out. Silly me, I should know better. You want both.

I'd like to see the day of the week represented as a number. While the processor may know the date and time, the A-B's (with which I'm familiar) do not know if it is Monday, Tuesday, etc. And yes, I do have logic running to solve this problem, it just seems it would be sooooo simple for the processor to produce this useful bit of info.
Why clutter of a perfectly good PLC with that stuff. There should be libraries similar to the Step7 libraries where you include what you need but don't force others to waste their precious CPU time do date time calculations if they aren't required.

Absolutely, and the IP parameters should be accessible and modifiable from a small LCD on the front of the unit.
No!!! That is extra money for a LCD that is used once. After that the controller is stuck in a cabinet and not seen again. What good is the LCD then. Ethernet should be configurable over Ethernet. How simple is that?

In the distant future ... I wish that there is a common object-oriented programming package that integrates al and everything seamlessly into each other. Logic code + data + alarms + hmi object + multilanguage user texts + multilanguage comments etc. A program change in an parent object shall make all derived objects update automatically throughout the project.
Would be nice if this was an open standard too. So that you could freely choose the PLC hardware vendor
Isn't that what PLC Open is all about? Can you herd cats?

You should read the threads on the embedded forums that complain about bloat code when using C++ over C. All this has a cost. It takes CPU time to dereference the reference to a reference to a reference to an object. I think JesperMP is setting the bar quite high for Bubba.

How about, when I open the controller tag browser in Logix5000, pressing the letter 'N" will go to the first tag that begins with an 'N'
It is called intellisence. It isn't that hard to implement it. I just told a programmer to do it. Seriously, it just takes time and money and a lot depends on the priority list. In our case the motion controller comes with a ton of predefined variables. It is hard to keep track of all the tag names and how the tags are spelled so something was needed to make it easier for the programmer to remember and spell the variables. On small PLCs I doubt there is the same need.

Now for my list. I think more in term of not what I would like but what would reduce the problem we see in the forum. My first reaction is usually "your PLC is stupid and you need to upgrade".

1. PLC should not cripple the instruction set of the underlying micro controller. I can easily do 64 bit signed or unsigned integer math on a 8 bit micro controller because they have these instructions
Add with carry
Subtract with carry
Shift left into carry
Shift right into carry
rotate left with carry
rotate right with carry
The carry bit makes it easy to do multi precision math. PLCs do have carry coils but no one seems to use them.
I doubt a 64 bit counter will over flow anytime soon.

Multiplies should be NxN to 2N bit in precision and divides should be 2N/N = N bit quotient and N bit remainder. There are some cool tricks that haven't been discussed on this forum that can be used your multiplies have provide a high and low register result.

Math instructions should work on signed and unsigned numbers. An unsigned add should cause an overflow error.

Rounding should be selectable. 5/3=2 is ridiculous in many cases. Encode, Decode instructions and bit count instructions should be available.

All PLCs should provide access to the hardware clock. Timer and coutners promote bad programming practice. Timers should be called delays since they really don't find the time between two events.

I think my suggestion would reduce the number of threads bit shifting, over flow, finding and counting bits etc.

And for Pete's sake, it should be against the law to sell a PLC without a toggle or exclusive or function.
 
Peter Nachtwey said:
Cheap Ethernet is exactly that and you get what you pay for if you are lucky. Communications take processing power. Lots of it. So you can get cheap Ethernet without a processor or get an Ethernet card that has a processor dedicated to the Ethernet.
I do not disagree with you. Beckhoff has taken a sensible approach by letting the ethernet i/o (EtherCat) be handled by a dedicated FPGA, and the 'regular' ethernet be handled by the CPU. For the 'normal' use of the ethernet services such as programming, hmi, database logging, the CPU load will be neglible.

Peter Nachtwey said:
Isn't that what PLC Open is all about? Can you herd cats?
I dont see my wish coming true, it is just a free "what-if" thought of mine. But I cant see why it should be impossible to achieve in principle.
Rather than a truly open standard, we may hope to see a multiplatform vendor pave the way. CoDeSys comes to mind.

Peter Nachtwey said:
Are you asking to download a SQL database into a PLC? If so this idea is nuts. I don't know of any current PLCs that have a SQL data base to upload. That would require a lot of bandwidth while transferring data let a lone the memory requirements on the PLC
I assume that we are 'merely' talking about for example recipe data. Or cyclical logging of data to the database. In other words, nothing new, only directly integrated into the PLC.
And Beckhoff has this already.

Peter Nachtwey said:
You should read the threads on the embedded forums that complain about bloat code when using C++ over C. All this has a cost. It takes CPU time to dereference the reference to a reference to a reference to an object. I think JesperMP is setting the bar quite high for Bubba.
All the complexity should be handled by the programming software / compiler.
I think it would not be more complex than the separate PLC and HMI programming packages we see nowadays.
As to performance penalty, the PLC runtime would be unaffected by the HMI runtime. The PLC runtime has a higher priority, and runs with the set task scan times.
 
Getting accurate crystal cost money and even then they aren't perfect. Day light savings time is a self inflicted wound. Use zulu time or move to some state that doesn't have day light saving. Get your state to repeal day light savings time.


What is a standard network application?


Ah, so you want to transfer text and just use the Ethernet as a serial port. What does the serial port do with the data then? One can transfer binary data over serial ports too.

http://en.wikipedia.org/wiki/Network_Time_Protocol - I have no idea how heavy of a protocol it is, but I enable it on every computer I use and it's keeps them all in line with no intervention. Linux and Windows both have implementations. At work our entire computer network is synced and the only clocks that are ever not in line with the official U.S. time are my PLCs and the cheap quartz wall clocks.

Standard network application? Anything that uses the TCP/IP stack to transfer Binary or ASCII data via TCP. I despise the 'man in the middle' model of using an extra PC for transfering data from PLC to server side software. It's expensive (extra liscence & hardware costs) and amounts to a giant kludge with an extra failure point (especially if the PC is running a heavy OS like XP). I'm really not a fan of OPC for simple data transfer.

A lot of the systems I deal with interface with UNIX based warehouse management software at some point. The PC between the PLC and the server is usually the component that fails. I just want to talk directly with the WMS software via TCP.

The PLC is very reliable. The redundant *nix based servers are very reliable. Why do I need an XP based PC running some crappy proprietary software to get these two systems talking?

I don't understand your point about the serial port. The point is that I need to transfer data from the PLC via our companies network... What the hell good does a serial port do for me unless I use a serial server? Seems like a pretty ridiculous approach when I paid to get a PLC with an ethernet port...

Apparently PLC manufacturers think that ethernet cards are only there to talk to their own software and gobble up more money if you want to do anything else with them?
 
Always thought the only instruction missing from all processors is "ESP"

Then we can deduce what the operator really wanted to do !!
 
FREE PROGRAMMING SOFTWARE!!! We pay enough for the hardware anyways...

Really? Free software? When my company sells a machine, the man-hours of software development are charged for. Your argument that my customer is buying a machine from us doesn't entitle him to my genius for free!
Pp
 
When my company sells a machine, the man-hours of software development are charged for.
Yes but do you bill them separately for it? I mean, do you send them the machine with no PLC or HMI programs, and they have to buy those from you separately? I'm being rhetorical of course, but that's what's so nonsensical about the way PLC hardware and software is sold. I certainly realize that software development takes time and money, and I'm willing to pay for it, but why not just work it into the cost of the hardware? Especially since a certain vendor's programming package only works with their hardware. Then they could do away with all those ridiculous copy protection schemes.
 
Yes but do you bill them separately for it?
No, but it can only be used once (on the machine which its controlling). Programming software can be used to develop tens, or hundreds of applications throughout its life.
Every machine we sell has a charge for the software.
The equivalent would be each time you buy a PLC/HMI/Servo/whatever, you get a one-time-only piece of software to develop your application.
Pp
 
Hello all,
For free software try Vipa 100 series plc's the software is free but the plc is digital only. If you need more the full blown Step 7 like software package is only about $800.00 US and it programs Siemens PLC's also.
 
I'm curious. If a customer buys a machine and pays for the machine plus the software charge. Then later buys another machine. Do you charge again for the software?

Yes; but it's not a seperate charge. The SW is as much a part of a machine as the bearings, nuts, bolts etc. Prices are set with material and labour charges.
 
hello ihave small problem ihave program for convoyer belt to filling buttle by water . convoyer start move until buttle under the valve stop and valve start after buttle full convoyer go to com again buttle . my program dont stop or stop after full buttl and dont move again please help mee thans
 
co2 - get it into your thick head - start another thread with full information - PLC - software etc. Do not tack onto another thread that has nothing to do with your request!!!
 

Similar Topics

Hi, I have a query that if omron PLC supports mail features , which series Please name latest series wise
Replies
0
Views
1,052
After making my latest video and discussing some features about Beckhoff and a few features that are undocumented or buried very deep, it came to...
Replies
5
Views
7,962
Hi sir, Currently Im studying my post-graduation in Process control Instrumentation Engineering and Im working on a project involving automation...
Replies
4
Views
4,884
The past week we received a new piece of equipment from Germany which utilizes siemens controls. Typically in our company we use A.B. controls for...
Replies
9
Views
176
the conveyor can stop because of a safety sensor or safety switch. And also it can stop because of an object jam detector sensor. If the conveyor...
Replies
5
Views
186
Back
Top Bottom