David Wisti

I use XP mode to support my Labview 8.5.1 real-time applications. Everything works fine and I don't have any complaints. You can not have real-time Labview 8.5.1 and anything newer then 2011 on the same machine, unless you use one in a VM.

I'm curious, why are you supporting older versions of the protocol? What is auto negotiation in Websockets?

Wow that is a nice mirror! I've updated the Websocket code and wrapped everything into a class. Also updated the chat client and added in a chat server that echos back what you send. Still struggling with the close handshake and I'm not sure if its 100% yet. WebSocket Chat.zip

Yes, Its similar to NI Ethernet IP toolkit. I currently use NIs toolkit for communicating to SLC5 and Contrologix PLCs. Its well worth the 500 beans. However, if you have to communicate to a Allen-Bradley PLC5 over Ethernet, then NI's EthernetIP toolkit is not going to help you. I posted some code above that can help if your using a PLC5.

If echo.websocket.org is not working. You can also use the above websocket chat client with the following in host: node.remysharp.com:8001 Note that the above websocket server does not echo back the chat. You can use Google Chrome and connect to the Websocket server at: http://html5demos.com/web-socket

I've used the websocket code posted here and updated it with the latest framing and mask. I created a simple websocket chat client that connects to echo.websocket.org. You can open and run "WS Chat Client.vi" in the attached Labview 2010 project. The server will echo back what you send. WebSocketChatClient.zip

While this does apply to the latest draft specification ("hybi-10") of websockets, there is a bug in "websocket handshake string.vi". The MD5 can sometimes contain an ascii line feed. If it did, the "Search and Replace Pattern.vi"would screwup the MD5. This is pretty easy to fix by moving the MD5 after the search and replace. Here an fixed image of the fix.

Russell, To get element number higher than 255 requires messing with the mask byte and understanding the PLC addressing for PLC5. See chapter 13 of the following manual: Allen Bradley DF1 Protocol and Command Set Reference Manual The PLC5 I was communicating to only required reading and writing a few words. I did not have to dive into fully implementing the PLC addressing for my application. Unfortunately, I no longer have a PLC5 here so I can test with. The code I posted uses "word range read" and "word range write" commands, see page 7-34 and 7-35 for more details on those commands. David

It should work, its the old style AB Ethernet protocol. I think the NI-Industrial Communications for EthernetIP is PCCC inside a CIP packet (Ethernet IP). With CIP you would need the correct firmware. All these AB protocols and the darn names are very confusing. I still don't think I have them figured out yet.

Here is some code to communicate to a PLC5 with CSPv4 (Client Server Protocol). This is just basically the DF1 commands wrapped up with a header and placed in a TCP packet. You can refer to the DF1 user manual to see the PCCC commands. The attached example "PLC5 ReadWrite Test.vi" will try to read N21:0 to N21:5 and write to N21:20. Info about the CSPv4 header can be found here. PLC5 CSPv4.zip

Back in the day when I was starting my first real time application, I did run some tests between user events vs queues. The trace execution toolkit was my close friend back in the day. I was worried that user events were a shared resource but it turns out they are fine to use in a RT application especially for triggering. However, there was one major drawback to user events, priority. If I remember correctly, you can not interrupt an event structure with another event structure (i.e. two different event structures). So, a higher priority event could not run until the lower priority event structure was finished. I ended up using single element RT queues and timed structures. But I still use user events quite a bit for sending triggers with data to other low priority threads. User events are very good performance wise in RT applications. David

Is this what you are looking for?

I already starting messing around with pre and post builds in 2010. Modifying the destination directory in the pre build means messing with projectitem methods with these tags: Bld_localDestDir Destination[0].path Destination[1].path There is a VI that NI made to help with this at: LabVIEW 2010\vi.lib\AppBuilder\GetTargetBuildSpecs.vi I don't have a working example yet but I'm getting closer.

Here's another one that I found in for my RT target build: NI_AB_TARGETNAME

Those absolute paths have been a thorn in my side for quite a while. I'm very glad to hear there is a workaround using the pre and post build events. Can you post an example explaining how this is done?

Looks like the downloads are missing. I'm pretty sure these were the latest. EtherNet_IP_CIP.zip EtherNet_IP_PCCC.zip

What about using a timed sequence instead of a timed loop?

Next thing to find out is if the unit your trying to communicate to is a master or slave. I'm guessing its a slave. The NI Modbus Library supports RTU and ASCII. If you have Labview DCS or RT, you could use the Modbus I/O Servers. I know that Modbus I/O Servers supports RTU but have never used it myself. The examples that ship with the NI Modbus Library are probably not going to work without some modification to the reading and writing. I would first try to read 1 word at the first address and see if you can get some data from the device. You could use a known Modbus master like Modpoll to help you troubleshoot the communication. Although the register def file is pretty cryptic (a nice secret decoder ring would be nice ), it looks like address 1 through 35 can be accessed with a read function and 201 through 203 from a write holding registers command. I highly suggest you read up a bit on the basics of Modbus first before you dive in and try to communicate. The focus here would not be the entire protocol but just start with understanding the memory map in Modbus and some of the basic function calls. It could be that addresses 1 through can only be accessed from a read input registers command. The equipment you have should have documentation describing which modbus functions should be used to communicate. Here a good start on Modbus info: http://www.modbus.org/specs.php http://en.wikipedia.org/wiki/Modbus

What kind of Modbus? TCP, Serial, ASCII, RTU, Plus, etc.

I use Beyond Compare everyday, very useful software.

If you using RT and need deterministic code, I would avoid notifiers. There is nothing wrong with Shared Variables (i.e. RT FIFO enabled SV's). If you really don't like Shared Variables then use RT FIFO's. Also, Type2 Globals can be used deterministically if the VI is set to subroutine priority and "Skip Subroutine Call if Busy" is selected. Here are some good links at NI with info about RT FIFOs & Shared Variables. Real-Time FIFO Frequently Asked Questions Notifiers cause a lot of jitter, use single-element RT-FIFOs instead. Monitor for Empty State in RT FIFO Enabled Shared Variable Real-Time FIFO for Deterministic Data Transfer Between VIs Avoiding Shared Resources

Wow! This is very nice! And the code is unlocked!

or you could use Greenshot.

Looks like keyword substitution does not work in Labview 2009. VI Descriptions, comments, labels, etc. are not in ascii anymore.

Sweet! Downloading now.