LabVIEW
Can LabVIEW be used to activate a test device running on a Keyence PLC programmed with Keyence Ladder Logic?
The OPC solution must come from the hardware manufacturer or a third party working closely with him. National Instruments can't and won't support all zillion devices that ar out there themself. National Instruments however does have a variety of OPC solutions for their software environments LabVIEW, Lookout, and LabWindows/CVI and their derivatives. With it you can always access existing OPC servers that interface to your specific hardware. I'm almost 100% sure that there are OPC server solutions for Keyence hardware out there.
@Giridhar_Rajan wrote:Rolfk,You are right. I tried to contact NI abt. OPC server, but it does'nt support Keyence PLCs. Anyways, we are using Keyence PLCs for almost all our projects, so I'll check the reliability of my keyence library in a couple of projects to ensure that it works under various conditions. Are there any standard methods used to check such libraries??
As to testing your own libraries there is only one thing. Write small stress test applications that try to get the worst out of your library in terms of throughput, random access, block size access, long term stability etc. If it survives this then your library is ready for production environment. If you see errors then fix them until you don't see any anymore. It may sound stupid to hunt for errors so actively but if your library needs to work in a production environment, any error you will find later while your application is already supposed to work properly will cost you a multiple of time and money to fix and may even cause loss of lots of money due to production interruption etc. That is usually the reason to go for OPC if there is one. While you can get a bad OPC solution too, they are usually tested quite well and work reliable, once you have figured out how to set them up and configure them properly. And if you happen to have gotten a bad one, there are almost always third parties offering an alternative for the same hardware.
Rolf Kalbermatter
Message Edited by rolfk on 07-03-2006 08:53 PM
Basically there are a number of limitations in respect to data throughput. I can't speak for the Keyence PLCs but the implementation for the AS511 protocol for Siemens S5 PLCs was a challange. I'm not sure if your observation that you need to wait 10ms between commands is right. It might be but then the internal CPU is either overloaded or you are not using the right commands to deal with what you want to do.
@Giridhar_Rajan wrote:Hi,I'm trying exactly the same these days and already found a few loop holes. Till now I have managed to fix it, lets see how many more need to be fixed. But the problem i'm facing is that, serial communication is very very slow. I have to wait for at least 10ms between two commands. We now plan to look for other PLCs too for future applications. So, I would like to know what kind of communication interface options do we have with PLCs, so that my communication wait time is reduced to 1ms or less. Also can I give multiple commands parallely in any of the other bus, b'coz I know I can't do it with RS-232.
For instance the used programmer port for the AS511 protocol on Siemens S5 supports only 9600 baud and that is of course a severe limitation. It means that even if you get full speed there is a maximum of about 1000 characters that can be transmitted. The AS511 protocol is quite complicated in that you have to send for each message a 3 way handshake with 1-3 bytes in each packet and then after the actual data some more handshaking. This means that if you want to read or write a single register of two bytes you end up with way over something like 80ms for this operation. If you instead want to read or write 20 consecutive bytes the entire duration of said operation increases only with about 1ms per additional byte. Obviously reading or writing two independant registers that are for instance 20 bytes apart in the PLC memory will require at least 160ms. Doing the same in a single buffer read operation throwing away the superfluous 18 bytes will only require about 100ms. Provided you program with LabVIEW memory performance issues in mind you can completely ignore the additional processing time LabVIEW needs to spend to do some more or less involved buffer parsing, combining, and separating in comparison to these huge times you get with slow serial port communication.
I ended up implementing quite an involved VI server that queues up write operations and then combines multiple writes into one message. Basically I scan about 4 times a second the queue and check all current requests and if they are not more than about 10 bytes apart I combine them writing in fact a larger buffer. A similar aproach is done for reads where each item has a scan rate and about 4 times a second the entire list of input items is scanned and all items whose scan interval has elapsed get collected and again combined into larger chunks to reduce byte throughput.
The whole system works now reliable and gets almost the maximum theoretically possible throughput but I debugged about 3 weeks before this combining and all the special conditions where fully working together with the fact that communication errors do occasionally happen and I want to have the server simply skip the operation on such incidential errors and continue without interruption. But to be honest the code that does this all isn't one of the cleanest I have ever written.
In restrospect if I would have to do it over again I would try to find a good working OPC solution instead or even more likely try to convince the customer to not use this poor mans communication interface but go with a real communication interface instead eventhough it costs some money. For the work I have done we could have gone with a full blown Profibus interface instead and still be cheaper and get easily about 50 times the throughput.
Rolf Kalbermatter
Message Edited by rolfk on 07-05-2006 09:09 PM
