Hi,
It’s my first post in this forum… So nice to meet you all! 
I’m currently working on a project where I will need to measure a duty cycle on 8 channels during more than 100h. So I need to automatize the data recording and I will do this through LabVIEW.
So far, I’m able to connect to the server, get the connected devices. But I can’t select an active device (I got no answer, not even a NOK) and get an error (56: Timeout When Communicating Between LabVIEW and Network Devices).
For a better understanding, I attach my source code.
Saleae.zip (25.9 KB)
Does anyone have experience with this API and LabVIEW? What am I doing wrong?
Thank you in advance!
Hey @julien.matthey welcome to the forum, and nice to meet you! We unfortunately don’t have much experiencing running our automation utility through LabVIEW. Regardless, we’ve interacted with users in the past who have gotten it to work.
When successfully getting the connected devices, are you calling get_connected_devices and receiving the appropriate response for it? I’m not quite sure how that would appear in LabVIEW, but if the response is as you’d expect, then that’s good news.
In your subsequent call to select_active_device, can you confirm that you are using the index of the desired device as returned by get_connected_devices? The timeout could be related to an invalid index argument.
Hi @timreyes,
Thank you for your reply.
Yes, I’m calling get_connected_devices and I get my device as described in your documentation. I then use this index as a parameter in the select_active_device command. However, I get no response from the analyzer.
Would adding a space after the comma (as in your examples) cause unknown behavior?
Thank you in advance for your answers.
Regards,
Julien
Hi Julien,
That’s strange. Spacing after commas should not matter. The command will work whether there is no space or a space. Either works.
select_active_device,1select_active_device, 1
The next thing I’d like to know is where the failure actually occurs. When the command times out, can you tell if select_active_device actually did anything? I’m wondering if the command actually executes, but LabVIEW doesn’t receive the ACK signal so it can’t continue.
One way to check is to do the following:
- Run the Logic software in simulation mode (i.e. no logic anlyzers connected)
- There should be 3 Logics “connected” now. These are just simluation logic analyzers.
- Here’s what capture settings window should look like. Select Logic 8 for now (that’s device 1)
- Now run the following in LabVIEW
select_active_device, 2
- The device selection under the capture settings window should change to Logic Pro 8. If it didn’t, then the command did not reach the Logic software. If it did, then the command ran successfully, but the response is somehow not reaching LabVIEW.
It works now! The problem came from my TCP setup!
Thanks for your support!
2 Likes
Another question about my application:
What I am trying to do is to monitor all 8 channels for an indefinite period of time (100+ hours). On these 8 channels, I need to measure the duty cycle on each cycle of the DUT.
In fact, these are 8 sensors measuring the rotation of a gear wheel. Each step of the wheel will generate an edge on the sensor. My application needs to make sure that even after 100 hours, the sensors still measure all the edges without any problem. That’s why I need to measure the duty cycle because the gear wheel will always turn at the same speed.
Is it possible to perform such a test with Logic Pro 8?
Thanks in advance for your answers!
My Pulse Stats measurement extension for Logic2 may help. It will give you a statistical summary of the high and low periods in a trace selection which will help catch outliers. For 100+ hours of data even at a very low sampling rate it will be slow! You may find it works better to export the data and use an external application to check things like cycle to cycle duty cycle, total pulse counts, or anything else you want to pull out.
@julien.matthey That’s quite the long capture! As @P.Jaquiery mentioned, expect our measurement extensions to process data for awhile, especially if you draw your measurement range across a large portion of your 100+ hours of data, and if you have a high density of edges (i.e. the higher the frequency, the more edges our extensions need to process).
Specific instructions on how our measurement extensions work are described below:
Hi Julien,
I am currently using your labview project for my own purpose. Could you explain to me what was the problem with the TCP setup?
Thanks in advance for your support.
Best regards,
Frédéric LEAU
