I have been asked by a customer if we can integrate a Fluke 1735 into our DAQ installation so they can access the meters functions etc through our Labview coded program. Contacted Fluke and they said that they had no LV drivers and only supplied their own software for logging etc.
They also said that there were no manuals available giving communication protocol, registers etc.
Has anyone done anything with this meter using Labview or know if a programming manual is available so I can create the vi's?
Thanks for link but opened them and it appears to be just for a USB to 9 pin serial coms port connection using Flukes own software.
I did a search on our Instrument Driver page for all Fluke instruments: http://search.ni.com/nisearch/app/main/p/bot/no/ap/tech/lang/en/pg/1/sn/catnav:id/q/fluke/
Although I could not find your particular model you can always communicate with the device through the built in VISA functions in LabVIEW. VISA is a high level API that calls low level drivers. It will allow you to communicate with your device over USB, serial, GPIB etc. As long as you know what commands to send the device you will easily be able to read back the data. If you have a look at some of the other drivers you will quickly see how VISA has been used.
If you then fancy creating your own set of Instrument Driver VIs, here’s a guide on how you can do this: http://zone.ni.com/devzone/cda/tut/p/id/12116
I would also recommend that you take a look at the Direct I/O and Instrument I/O Assistant section of this article too: http://zone.ni.com/devzone/cda/tut/p/id/12116
I hope this helps you.
Did you ever find a solution for this? I just purchased a Fluke 1735 and would love to find a way to programatically grab actively measured values from it with a remote program. I discussed the issue with Fluke, and they said they do not have any communcation drivers for this particular model at this time. I get a feeling that this is on purpose to force you to buy a higher-level (more expensive) power meter in order to connect/automate it with an external system.
The 1735 has really nice hardware, but its software is lacking....You have to use their proprietary software to download saved scope plots, events, and saved screenshots. You cannot export the downloaded data. Even though it has a physical USB connection, the driver appears to emmulate a traditional COM port simply send serial data via USB. I probed the comms data stream and was able to isolate some of the commands. I was then able to actually telnet to the 1735 and get it to respond, although not in a useful manner. The commands are not like anything I've seen before. You can see the software initialize the connection, have the meter ID itself, and then request data dumps, but that's about it. I'm not sure if there are additional commands. Interestingly, it appears the screenshots are simply not transferred bitmaps.....the meter actually sends the text from the screenshots, and the program puts it back together and "re-creates" the screenshot on your PC (A very efficient way to store/send data as long as you can post-process it back into a virtual screenshot).
I would love to get a command list for this meter. Perhaps dumping the real-time measured values would be an option....if I only knew what the command is.
Mahdeih, I find your statement of "you can always communicate with the device through the built in VISA functions in LabVIEW" to be fairly presumptious. While you can do just about anything in Labview, you are limited to whatever communcation ability the target device has. If is has none (or near-none), Labview is helpless.
Using the posted link, I searched for any new Labview drivers for the Fluke 1735, but did not find anything.
I think the ball is currently in Fluke's court.....hopefully I can get some more info from them.
Please post if anyone has had any luck communicating with the 1735.
Although Labview has the capablity to communicate with various equipment (and I do use it for that quite a lot) its not much use without the devices registers etc that you are tryinng to communicate with.
In the past I have streamed data from a device after guessing its coms settings and logged the response working backwards to determine what it all meant. Due to cost though this route is no longer viable so if I do not have the information for a device it ends there.
This particular project was a typical point in case where I spent a lot of time on this to put our offer to the propsepctive client who then changed their mind and trotted off into the blue yonder!