Jump to content

BrentonLang

Members
  • Content Count

    33
  • Joined

  • Last visited

  • Days Won

    1

BrentonLang last won the day on July 2 2012

BrentonLang had the most liked content!

Community Reputation

3

About BrentonLang

  • Rank
    More Active
  • Birthday 07/16/1984

Profile Information

  • Gender
    Male
  • Location
    Brisbane, Australia

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2011
  • Since
    2008

Recent Profile Visitors

836 profile views
  1. Hi everyone, I've got a problem that I'm desperately in need of assistance. The basic setup is that I've got a SLC5/05 Allan Bradley PLC system communication to a screen (HMI). I've thrown an ethernet switch in between the PLC and screen and everything continues to work correctly. I have then connected a CompactRIO to the switch, which has been setup to 'sniff' the PLC tag packets. This works successfully using the Industrial EtherNet/IP Communications LabVIEW Module. The problem I'm having is on a second set of hardware, where PLC tag reading works on 1 PLC, but not another. I am also physically using a different cRIO, but with the exact same hardware and cRIO image has been copied. The PLC hardware and firmware should also be the same as well. All IP addresses are the same for both systems, and the PLC can be pinged successfully. Actually, as far as I'm concerned it's a duplicate system in every way. I can also tell you that when I request for a PLC tag reading, I get the following error code -251723745. I've spoken to NI who say that this is not a generic LabVIEW error but relates to a PCCC status error whose code is 0xF0. This error is within range used to indicate Object Class Specific errors. However, I don't know enough about AB PLC systems to understand what this means. Is there anyone who can help me? Anyone with similar experiences or troubles with EtherNet/IP protocol using LabVIEW. Thanks. Brenton Lang
  2. Hi Guys, Simple question. I assume that some responses may be a simple "Yes" or "No". Can TDMS files have different file extensions than.tdms, if the file is created by LabVIEW?? Second question, what is the difference to TDMS v1 and v2?? Thanks for your help. Brenton
  3. This is great! I'll be adding this functionality in my current project. Thanks again.
  4. Thanks for your help Ned. It looks like a reasonable alternative is to create a proxy class or proxy service. I'm a little ignorant when it comes to .NET. Does anybody have any examples on how to create a proxy service, but more importantly any examples on importing the proxy service into LabVIEW? Does it still use the Import Web Service tool?
  5. Hi Everyone, I'm using LabVIEW 2011 SP1 and am trying to use the "Import Web Service" to consume a WCF web service. I can connect to the service no problems, but when it comes to the window that lists the methods to import, there seems to be no methods available (even though I know there is). I've read on NI forums back in 2009 that WCF is not supported by the Import Web Service tool because it was written using .NET framework 3.0 (or prior), however, I'm using .NET framework 4.0. I would have hoped that NI would have updated this from 2-3 years ago. Does anybody know why the methods are missing? I know I can use a .NET dll, but that will take some more time...
  6. Good point Bobillier. However, this may only be an issue if many relays are switched simultaneously, plus it depends on the relay coils. Still, it's always a good idea to design with isolation and protection in mind.
  7. I believe the ULN2803 will work for you. Just be sure to connect a 12V supply to pin10 and then you'll be alright.
  8. I agree with Shaun. If the device doesn't need to be connected via USB, you'll have far more power options using a PCI card, or similar. But it comes down to the relays you use and their coil power requirements.
  9. If you do decide to use a custom interface PCB, but are still thinking of a cheaper alternative to the USB-6501, another option might be Arduino. LabVIEW has a Toolkit called the NI LabVIEW Interface for Arduino Toolkit, which is free. There are quite a few Arduino hardware options that include more than 20 DIO lines. LabVIEW can control the Arduino via the usb port (just like USB-6501). The biggest negative however would be that more effort is required than the standard NI hardware, as you'd expect. The thing I like about Arduino is the form factor. You can build and design your custom interface PCB as a prototype Arduino Shield board. The shield quite simply plugs into the Arduino, creating a "stacked" devices. There is also an existing Arduino Shield that includes controllable relays...
  10. I was going to suggest the NI USB-6501. I've used it before to create a large 5x 7 segment numeric LCD (to display any connected LabVIEW numeric indicator). It's incredibly cheap and simple to use. However, I'd recommend designing an interface PCB to "current amplify" the DO lines. The main reason is because the USB-6501 can only supply a maximum of 65mA across all 24 digital lines, that is not enough current to switch 20 relays at the same time. Even if you want to switch 1 relay at a time, it would be very hard to find a relay that will switch from 8.5mA. An interface PCB with simple switching transistors would even do the job. So it is possible, but you'll need to check the required current (and DC voltage) to switch the relays that you've chosen. The USB-6501 is a great cheap option, but is very limited in terms of output power.
  11. Do you have fluorescent lights in the room? They transmit the mains frequency rather well. Most countries have an alternating current frequency of 50Hz, but I think America is typically 60Hz. Might be your issue ?? If the analog input reference is not grounded, the voltage range of the noise can be quite noticeable.
  12. This is the main reason why I'm leaning towards a lower-level design. I'd like to have the flexibility to use third-party devices at a later stage. It would be nice, but not a requirement. This looks very interesting, I'll take a deeper look.
  13. Love the feeling of a new LabVIEW project...

    1. jcarmody

      jcarmody

      They're always fun to start, huh?

  14. Hi everyone, I'm wanting to open up the floor for your opinions and past experiences with designing a network communications architecture. - There will be one server, written in LabVIEW on a Windows based PC. - There will be multiple remote clients programmed in LabVIEW on cRIOs. - All devices will be connected via a wireless network, and all cRIO clients should have good throughput to the server. - It should be designed for bidirectional data flow, however the clients will do most of the talking. - Data sent will be, status packets, images, PDF documents, and other information. - Clients will not be continuously sending data, such as a typical DAQ system, but more reporting on events. I'm leaning towards the TCP socket option, but would like to consider higher-level forms of NI-propriety designs, such as Network Shared Variables or Network Streams, which I haven't had huge amounts of exposure to. Thanks for your opinions. Brenton
×
×
  • Create New...

Important Information

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