BrentonLang
-
Posts
33 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by BrentonLang
-
All fixed. It wasn't actually a problem, just a miscommunication. -
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
-
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
-
Put your LabVIEW in the Tray -- Once and for all
BrentonLang replied to Stinus Olsen's topic in Code In-Development
This is great! I'll be adding this functionality in my current project. Thanks again. -
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?
-
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...
-
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.
-
I believe the ULN2803 will work for you. Just be sure to connect a 12V supply to pin10 and then you'll be alright.
-
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.
-
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...
-
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.
-
Sine wave noise signal on analogue when nothing connected
BrentonLang replied to KWaris's topic in Real-Time
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. -
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.
-
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
-
Programmatically read serial number of S.E.A. Gxxx cRIO Module
BrentonLang replied to BrentonLang's topic in Hardware
I'll give it a go and hopefully will report some good news. Thanks for your help asbo. -
Programmatically read serial number of S.E.A. Gxxx cRIO Module
BrentonLang replied to BrentonLang's topic in Hardware
Still waiting for a reply from SEA -
I'm using a cRIO with multiple NI modules and an S.E.A Gxxx 3G Module installed in Slot 1. For all NI modules I can programmatically read its corresponding serial number using a property node on the FPGA. However, this is not the case for the Gxxx 3G module, as no properties appear for this module. The frustrating thing is that in order to access this module from the real-time code, the module's serial number is required. For a single cRIO unit this would be acceptable, however I'll be deploying many many more than just a few and I really want to avoid manual inputs for obvious reasons. Can anyone please help me? Thanks.
-
That is our second option. Ideally we'd love to have everything inbuilt in the cDAQ.... just for form factor.
-
I'm needing two c-series Modules for the CompactDAQ. They are a GPS module and an accelerometer module. I know that S.E.A. sell a GPS c series module, but it is only compatible with cRIO, not cDAQ, obviously with the different interfaces. Does anyone know of any companies that sell GPS and accelerometer modules for the cDAQ? Thanks.
-
So do you think the problem is with the VI saving, or with the Project? Try something pretty stupid and create a new project and see if you have the same problem? Might be a project setting issue.
-
This is a very good article, thanks for the link. As I am an iOS developer, it's very useful. However, for those who aren't an iOS developer, this is a little useless and would be better off using the VIremote app. Thanks again though.
-
I'm sure there are ways to accomplish what you are asking for all mobile phone device types. However, I know for an iPhone/iPad there is a way. Look into the app "VIremote" or "VIremoteFree". Once you've download the app, goto the following link to download the required VIs to communications to the iPhone. http://throwlab.com/VIremote/index.html It uses WiFi or 3G to transfer data via a specific comms protocol. The good thing with this is that all the hard work is done. Is this what you were after?
-
Is this also the case for ARM Development? As LabVIEW generates C code?
-
My previous phone was a HTC Windows Mobile Phone. I took the plunge to an iPhone. I must say, yes it is restricting in some ways, but I'm very happy. I dare say that my next phone would probably be another iPhone. Since then, my wife got an iPad2 for work (using the Citrix app) and for basic internet, e-mails and games. Plus about a year ago I got a MacBook Pro. I'm very impressed. If you asked me two years ago what I thought of Apple, I'd say, "waste of money, crap, never touch them". But I'm pretty happy. But yes I agree with JGCode, the iPad shouldn't replace a computer (not yet anyway). It's more of an accessory, or a tool. I must also add that my mate here at work just got a new Android phone. He loves it, but would have a few apps crash every day. I couldn't stand that.
