Jump to content

As of July 17, 2015, the LabJack forums here at forums.labjack.com are shut down. New registrations, topics, and replies are disabled. All forums are in a read-only state for archive purposes.

Please visit our current forums at labjack.com/forums to view and make new posts. To post on the current forums, use your labjack.com login account. Your old LabJack forums login credentials have been retired. There are no longer separate logins for labjack.com and LabJack forums.


Photo

U3 DAC fast ramp


  • Please log in to reply
7 replies to this topic

#1 Gyozo Izsak

Gyozo Izsak
  • Members
  • 4 posts

Posted 24 August 2012 - 03:11 AM

Hi there, I'm using Labjack U3-HV to emulate throttle sensor signals in vehicles. This is to automate special tests like: throttle pedal Tip In and Tip out under various conditions. The problem I am facing at the moment is more or less the following: Under safety critical events the driver can perform a "kick-down" which means an extremely fast push-down of the throttle pedal. (To avoid a collision with another vehicle, escape from a dangerous situation etc...) These "kick-down" events can happen within 40ms (I'm not kidding we've tested it :) ) During this period I should be able to gradually increase the DAC outputs from ~0.7V to ~4V to simulate the sensor characteristic. (The ECU's sampling rate for sensor signal evaluation is 2.5 ms). So I've made some code using the eGet function to perform the ramping and made a basic timer driver using the internal clock signal to measure how often the values are updated (this part is pretty much a cycle time measurement). The result was around ~10ms, which is a bit slow for us. (and cycle time was a bit volatile too) I've seen in the labjackguide.pdf that for inputs there is a "streaming mode" to improve the timing constraints so I started to wonder if there is a similar way to set up a target voltage and a ramping rate for DAC ports too. I'm using DEV-C and I stated from the basic DEV-C example program. Any info would be highly appreciated! Best Regards, Gyozo

#2 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 24 August 2012 - 07:49 AM

See the following app note:

http://labjack.com/s...form-generation


Confirm that you are getting the expected command/response rates from Section 3.1. In particular, the ~0.6ms time with no analog inputs from Table 3.1-1:

http://labjack.com/s...users-guide/3.1

Download the VC6_LJUD archive to get the allio (All I/O) example, and follow the instructions from the Dev-C example about how to adapt VC6 examples to Dev-C.

Use good programming techniques to achieve these speeds in your actual application. In your loop that creates the ramp, make sure minimal other things are going on (minimal processing/calculations, no file i/o, no screen updates), and make sure that when that loop is executing there are no other threads executing. Shut down as many other Windows programs and processes as possible. Use task manager to assign top priority to your program's process.


You might consider the LJ_ioPUT_WAIT method mentioned in the app note. The question is how many updates you can get in a single packet? The last few paragraphs of Section 3.1 have some info about this.

The low-level Feedback command has room for 57 bytes of data, and the response has room for 55 bytes of data (Section 5.2.5).

Keep your wait between 128 and 32640 us. That way the UD driver will just use a low-level WaitShort iotype for each wait, which means 2 command bytes and 0 response bytes (Section 5.2.5.2).

Each DAC update has 3 command bytes and 0 response bytes (Section 5.2.5.14).

That suggests to me that you can do 11 pairs of DAC updates & waits to make your ramp. Note that the steps will likely be smoothed a bit by the fact that the bandwidth of the U3 DACs is only 16 Hz.

#3 Gyozo Izsak

Gyozo Izsak
  • Members
  • 4 posts

Posted 28 August 2012 - 03:47 AM

Hi there, thank you for the detailed answer. I'm trying to follow through your train of thought but please clarify a couple things for me. So first of all I'm a bit confused regards to the low-level function descriptions. Is there any way to see/debug these low-level functions or the description within the guide is only for generic information purposes? If I understand you correctly by using and internal clock signal and this LJ_ioPUT_WAIT method the DAC ramp up- down can be handled as a "streaming" but in the sample code I found nothing related to this command or the low-level function. Can you give me something (a pseudo code or a C example) to show this wait method in reality? Best Regards, Gyozo

#4 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 28 August 2012 - 07:05 AM

Is there any way to see/debug these low-level functions or the description within the guide is only for generic information purposes?

The reason the low-level functions are documented is that some people use the low-level protocol directly, and don't use a higher level driver like the UD driver. In your case, I pointed you to the low-level functions not because you should use them, but just to get a deeper understanding of what is happening underneath.

If I understand you correctly by using and internal clock signal and this LJ_ioPUT_WAIT method the DAC ramp up- down can be handled as a "streaming"

Not exactly. There is no internal clock signal. Rather, the timing is dictated by the WAIT commands. The following topic has some pseudocode. Try it, and if you have trouble post a snippet of your code:

https://forums.labja...?showtopic=2969

#5 Gyozo Izsak

Gyozo Izsak
  • Members
  • 4 posts

Posted 28 August 2012 - 08:06 AM

Hi, I see. Okay, makes sense. I've tried the Wait command. Does the channel, X1 and UserData parameters worth anything in this case? So if I have to set 2 channels parallel that means 8 command byte per setting so I can set roughly 7 values in every cycle for both channels... Can I interrupt the setting via adding new requests, or first the old settings will go through regardless? Best Regards, Gyozo

#6 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 28 August 2012 - 12:22 PM

x1 and userdata are ignored. In Section 4.3, if x1 or userdata are important there should be a comment. I agree on your math for 7 updates (both DACs and a wait) per packet. After sending a command, you must wait for the response, which occurs after the command is done. Any additional commands sent before the response are discarded.

#7 Gyozo Izsak

Gyozo Izsak
  • Members
  • 4 posts

Posted 30 August 2012 - 05:20 AM

Hi, thank you very much indeed, with the combination of single value setting/per cycle and multiple value setting plus wait command, I've managed to cover a huge range of gradient settings from 40 ms to 6 seconds. The only thing that bugs me a bit is that when the CAN communication is on (I use an MCP2515 CAN controller and SPI communication to reach it) the cycle time climbs up to 50-60 millisec/cycle. Its still fine as the DAC signal still smooth enough if the ramping rate is higher then 500 ms (and in the lower sections I use the bufering and the wait command) but I'm a bit worried that later when I extend the program with more I/O control functionalities and another SW (data acquisition tool) will also run in the background the cycle time will increase even more or become vulnerable to CPU usage via other SWs, which then eventually makes the DAC signal inconsistent or not smooth enough. I've seen in the documentation (section 11.4 Utilizing multicore processors) that Windows threading is actually an issue here. The document (for obvious reasons) focus on the DAQFactory related stuff, but it made me wonder: Is there any "best practice" solution to ensure that a single executable LJack SW gets a high Windows threading priority rating or even a whole CPU? I would like to avoid the situation where I hand over the SW to the calibration team, and it turns out that it cannot co-exist with any other application. Any info highly appreciated! Best Regards, Gyozo

#8 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 30 August 2012 - 08:21 AM

From a general standpoint, there are 3 things that I briefly mentioned in post #2: - Use Windows Task Manager to raise the priority of your process. I don't know if there is a way to do this programatically. - Avoid/minimize file I/O and anything that updates the screen. - Avoid/minimize running other programs. Uninstall everything so people can't run anything. Turn off auto-updates and virus scanners and anything else. Look at your list of running programs and processes to see what else can be removed.


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users