LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

WT5000_Yokogawa_read data_Update Rate_50ms

Dear All:

I'm having trouble using the sample program for the Wt5000.

I use the environment as follows
Communication method: tcp IP 100M

Number of target reads: 24 ITEMs

UPDATAE RATE: 50ms

Questions are as follows
When I set to read 4 Item data, the speed is in line with 50ms
But I changed back to 12 items and the data speed did not match 50ms

Request for help Thanks!

As shown below

S__113754119.jpg

S__113754121.jpg

S__113754122.jpg

   

0 Kudos
Message 1 of 4
(200 Views)

Hi hao,

 


@haohao11223 wrote:

I'm having trouble using the sample program for the Wt5000.


From your images it seems the sample programm runs as expected, so there is no "trouble"…

 


@haohao11223 wrote:

I use the environment as follows
Communication method: tcp IP 100M

Number of target reads: 24 ITEMs

UPDATAE RATE: 50ms

Questions are as follows
When I set to read 4 Item data, the speed is in line with 50ms
But I changed back to 12 items and the data speed did not match 50ms


Did you read the manual of your device? What does it mention about sample rates?

What does the spec sheet say about sample rates? (After all it's a "precision" DAQ device!)

 

Summary: that "precision" device needs some time to process your request, measure some data and send the response to your computer. Doing all this within 10ms for one sample is rather fast for such devices. When you start to request more than 4 samples/values you most probably need more than 50ms!

 

Again: read the manual of your device. Sometimes such devices offer some "high speed" measurement modes to allow higher sample rates - using specific commands with specific side effects…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO
0 Kudos
Message 2 of 4
(158 Views)

Dear  GerdW:

Thank you for your willingness to answer my question.

I've tried reading the manual and haven't found an answer.
I have uploaded the manual!

In fact, I also tried to use the original free software, which is very stable and can read 24 Item in 50ms.

So I thought I could do the same thing with the same hardware using labview.

But I use the example provided by the original factory, it is not possible to achieve.

Caused me to be very troubled... Recently the WT5000 software release can use 10ms.
The user immediately put forward the need to modify the software, hoping that I can also increase it to 10ms.
I am quite troubled at the moment.

If you have relevant experience, I hope to share more. Thank you.

0 Kudos
Message 3 of 4
(145 Views)

There are many possible reasons why that example can't reach the desired speed.

 

- Badly programmed: LabVIEW makes it easy to write code that works somehow, but to make it work efficiently often does require some real programming knowledge. Many LabVIEW examples and instrument drivers were written by people with little or no experience in programming in general and /or LabVIEW specifically.

 

- There are various ways to retrieve multiple measurements from a device, one is to query each measurement specifically. This method is very slow as for each measurement your program sends a command to the device, which has to receive it, decode it and then perform the operation to fetch the measurement from the internal memory and format it to send it back and your program then needs to receive it, decode it and display it somewhere. Or you can send a command that requests multiple measurement in one go. The entire overhead of sending, decoding, and performing the command and sending back the results is almost the same in either case, the only thing that changes is the slightly higher transmission time for the result as there is more data transferred back to your program. This is for most communication busses other than RS-232 nowadays an almost completely irrelevant amount of time and the actual time needed to send any command and receive its responses is highly dominant, pretty much independent of the amount of data that is requested.

 

- The parameters with which you operate a device can very much determine its measurement speed. For instance some instruments have measurement modes that are either fast and only somewhat accurate or very slow and extremely accurate, and often several variations in between. Choosing the right measurement mode for your measurements is not always easy and always requires you to really understand your measurement device to a very deep level. Your ready made Yokagawa application was written by a Yokagawa engineer who was both an experienced programmer, also in the programming language used for that program, and also very likely very intimately familiar with the device.

 

That application shows that your device is capable of the measurement speed that you would like to achieve but that your LabVIEW example is either programmed badly, or maybe uses a measurement setting that produces slow but extremely accurate results, or the wrong method to request multiple measurements in one go.

 

Unfortunately as this is hardware and pretty specific hardware at that, debugging it for you is almost impossible for us. We can't run that software to see the differences without owning that piece of hardware and studying your instrument manual is a tedious and complicated process that requires quite some time, which most people are not going to spend if it is not for a problem they have themselves.

 

It definitely is something that Yokagawa support is more suited to help you with, except that when they hear the word LabVIEW they will likely tell you that they can't support it as they do not have the software available to use. They could of course send you a principle command flow to use, that is able to reach your goals, maybe as Visual Basic or similar code, but it still would mean that you need to understand the device, the instrument driver and of course how to program in LabVIEW, to be able to transfer that code into a LabVIEW equivalent.

Rolf Kalbermatter
My Blog
0 Kudos
Message 4 of 4
(141 Views)