LJM_eWriteNameArray transfer speeds

13 posts / 0 new

Thu, 08/30/2018 - 17:04

eric11

Hi,

We would like to stream an output signal to DAC0 at 50 Khz, I've set up a sample using stream mode similar to the examples, but I don't seem to be able to transfer data down to the LabJack fast enough to support real-time operation.

In one example run, I timed LJM_eWriteNameArray writing 2098 samples in 95.78 ms, which is an effective rate of 21.9 Khz.

I'm running on a computer with a USB3 port directly connected to the LabJack T7.

Do you think it will make a difference if I connect it to a USB2 hub?

I've attached a VB6 code snippet of the example code being used.

Is there a better, faster way to get data down there or is LJM_eWriteNameArray the best option?

Thanks,

Eric

File Attachment:

sampleCode.bas

Fri, 08/31/2018 - 12:06

LabJack Support

LJM_eWriteNameArray is

LJM_eWriteNameArray is probably the best option.

However, USB has small packet sizes (24 samples max), so the maximum throughput with USB is reduced because the per-packet/communication overhead is greater per sample. This in in contrast to Ethernet, for which the packet maximum sample size is 254.

In essence, for eWriteNameArray:

24 is the best-throughput NumValues for USB
254 is the best-throughput NumValues for Ethernet (or WiFi, but WiFi has lower throughput)

I've attached a version of c-r_speed_test.c (which is customized from the c-r_speed_test.c in the LJM C examples). It:

Opens an Ethernet connection
Initializes stream out buffers
Starts stream
Performs 1000 iterations of LJM_eWriteNameArray and measures the time taken

With this test program, I'm able to get around 5.4 ms per iteration, so 47 kHz (1000 packets * 254 samples per packet / 5.4 ms per packet). Results may vary, especially depending on your network.

For comparison, for USB with 24 samples, the test program gave around 31 kHz. (1000*24/0.773) (On macOS with USB 3, no hub)

File Attachment:

c-r_speed_test.c

Fri, 08/31/2018 - 16:11

eric11

Thanks,

Why are we seeing lower rates than the 100 ksamples/second mentioned here?

https://labjack.com/support/datasheets/t-series/appendix-a-1

USB generally maxes out right around 100 ksamples/second.

The T7 has a typical maximum sample rate of 100 ksamples/second.

Are the rates different for transferring one way or another (to or from the device)?

Thanks,

Eric

Fri, 08/31/2018 - 16:20

LabJack Support

What was the max speed

What was the max speed attainable by the example provided in the previous reply?

"Are the rates different for transferring one way or another (to or from the device)?"

Are you using stream-out, command-response? To get max speed, stream-mode needs to be used.

Fri, 08/31/2018 - 16:59

eric11

Upon further thought, I

Upon further thought, I should probably be doing the signal generation as a LUA script.

I'll get up to speed and see if I can generate what we need.

That would eliminate the large data transfer.

Fri, 08/31/2018 - 17:30

eric11

What was the max speed

What was the max speed attainable by the example provided in the previous reply?

I will try to build your example and see what numbers I get.

Where does LJM_Utilities.h and LJM_StreamUtilities.h live?

I downloaded and installed the LJM Library from https://labjack.com/sites/default/files/software/LabJack-2018-03-12_1.exe, but can't seem to find these include files.

I'm also using an older version of Visual C++ that is not happy with the Long Long declarations.

Are you using stream-out, command-response? To get max speed, stream-mode needs to be used.

In the previously attached VB example I'm calling LJM_eStreamStart so I believe I'm using stream-mode.

Thanks,

Eric

Tue, 09/04/2018 - 10:28

LabJack Support

LJM_Utilities.h and LJM

LJM_Utilities.h and LJM_StreamUtilities.h are contained in the C/C++ examples download:

https://labjack.com/support/software/examples/ljm/c

In regards to long long, what is the error message? The only functions that use long long in LabJackM.h are LJM_NumberToMAC andLJM_MACToNumber, which you shouldn't need.

In the previously attached VB example I'm calling LJM_eStreamStart so I believe I'm using stream-mode.

Sorry for the confusion. There are two rates to think about.

1. You are sending bytes to the device via LJM_eWriteNameArray, which uses command-response mode.

2. You are receiving bytes from the device via the LJM_eStream functions, which use stream mode under the hood of LJM.

It's part 1, the sending of bytes to device (to the stream out buffer) that is constrained by command-response speeds. See "Command-Response Data Rates" on https://labjack.com/support/datasheets/t-series/appendix-a-1

Mon, 09/10/2018 - 17:11

eric11

So if I understand correctly,

So if I understand correctly, when we transfer data from the computer to the device, via LJM_eWriteNameArray, we are using command-response mode, so we won't have speed advantage of the stream mode.

If we do our signal generation via a LUA script, that will eliminate the transfer delay between the computer and the device, since the data will be generated on the device. I was looking at one of the LUA scripting examples for sine wave generation:

https://labjack.com/support/software/examples/lua-scripting/output-sine-...

and I noticed the comment:

--Note that faster(higher frequency) sine waves can be created using stream out

Can you do stream out via a LUA script, or does that need to be done on the computer where we have already learned we are data transfer limited because we are using command-response mode?

Thanks,

Eric

Mon, 09/10/2018 - 21:05

LabJack Support

Since Lua scripts can write

Since Lua scripts can write to any Modbus register on the device, Lua can generate stream out, without the transfer limitation. However, Lua and stream are both resource heavy. From talking to one of the firmware engineers, it sounds like Lua may not be able to reach 50 kHz stream out generation. I will try to write a Lua script to find the maximum Lua stream out speed.

Just in case—if your signal is repeatable, stream out can handle that, depending on the size of the signal. That would allow you to reach speeds greater than the approximately 47 kHz I was able to get.

Another possibility is to connect the T7 via Ethernet directly to your computer. That will reduce the variability of the network, which might possibly make the difference for you.

Tue, 09/11/2018 - 12:23

#10

LabJack Support

I was able to test the

I was able to test the maximum speed that I could write to the stream out buffer using a computer directly connected via Ethernet to a T7. Instructions for configuring that are here:

https://labjack.com/support/app-notes/networking/direct-connection-ether...

With that approach and the above c-r_speed_test.c, I was able to reach max speeds of around 68 to 71 kHz.

From talking to another firmware engineer here, it sounds like Lua scripts would be likely to generate stream out waveforms at around 4 kHz, so I won't write an example to find the exact speed.

Wed, 09/12/2018 - 17:25

#11

eric11

Just to close the loop on

Just to close the loop on this. I am seeing similar rates (if not slightly faster) when using ethernet.

Thanks!

Eric

Thu, 09/20/2018 - 16:05

#12

eric11

All,

When I do a performance test using LJM_eWriteNameArray over ethernet, I'm seeing transfer rates in the 90k samples/second range, which is great (no streaming going on).

If I try to do the same thing with stream mode (50000 scan rate, 2 channels) enabled, LJM_eWriteNameArray's transfer rate drops down to around 28k samples/second. If I lower the scan rate, the LJM_eWriteNameArray's tranfer rate increases. I take it the lower tranfer rate for LJM_eWriteNameArray when in stream mode is because the T7 is busy?

Thanks,