Jump to content

David Wisti

Members
  • Posts

    113
  • Joined

  • Last visited

Posts posted by David Wisti

  1. 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.

    I'm only just coming into this, but is this the same as NI's Ethernet/IP toolkit?

    http://sine.ni.com/n...g/en/nid/209676

    I saw that this existed in NI Labs before it was an official product, but those files have been taken down.

  2. Hey smarlow,

    Any progress in your idea of the community effort ? The code that you have uploaded does not work with Chrome 14. The hand shakes have changed in the recent version of chrome. I tried fixing the handshakes. But still I couldn't get the code working. The onclose callback gets called when I stop the LabVIEW code, but I think the onmessage callback is not getting triggered. I'm new to SVG, HTML5 stuff. Can someone post an update to this code to get it working on chrome 14.

    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.

    post-319-0-72419500-1318864710_thumb.png

  3. 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

    Hello David,

    Thank you for your code it is communicating with the PLC 5, but I have two issues that I thought you might be able to help me overcome. It looks like the element number is an U8 so I can't enter element numbers greater than 255. The other issue is that negative numbers are not read correctly. I tried to read from element 201 which should of been -22 and I read -17.

    Thank you,

    Russell

  4. 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.

    Hello David,

    Thank you for the code. I am wondering if you know if I need a certain version of the PLC firmware to run this code?

    Thank you,

    Russell

  5. 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

  6. 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

    I am writing an application where functionally I can use user events or queues to sen messages (triggers)O between threads. On the other hand, since this is a real-time application, if there is a significant difference in the CPU processor requirements between the two, I would definitely want to pick the more efficient method.

    I have implemented a solution using user events mostly because we use events elsewhere so the paradigm is more familiar. I am guessing that events add some small overhead versus queues, but is it much? Has anyone bench tested one versus the other? (I might need to do such a test myself, which is easy enough, but I thought someone might already have some results....)

    Paul

    • Like 1
  7. 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.

    You can now download LabVIEW 2010 (see this thread) and try it out (even just to eval for 30 days).

  8. 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?

    LabVIEW 2010 is out, and when I try entering a relative path by using the "..\" construct, I receive an error message stating "Paths must be absolute"

    At least now I have pre and post build events so I can move the project output to where I want them to be.

  9. 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

  10. EDIT: I should also mention this code will be deployed on RT.

    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

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.