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

A few questions about the U3 and the DLL with Labview


  • Please log in to reply
17 replies to this topic

#1 joeqsmith

joeqsmith
  • Members
  • 9 posts

Posted 30 September 2014 - 01:05 PM

I just purchased a U3HV and have started to look at the Labview examples.

 

It appears when reading multiple ADC channels, you make one call to the DLL per channel, calling GetFirstResult, followed by GetNextResult.  All of the examples appear to work this way except when using streams.  Is there a DLL function that will pass up an array of analog channels so only a single call to the DLL is needed?  

 

Why do some calls to the DLL require ASCII text commands (OpenLabJackS for axample) , while others require the text commands be converted to an I32 (using StringToConstant)?     



#2 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 30 September 2014 - 01:51 PM

 

 

It appears when reading multiple ADC channels, you make one call to the DLL per channel, calling GetFirstResult, followed by GetNextResult.  All of the examples appear to work this way except when using streams.  Is there a DLL function that will pass up an array of analog channels so only a single call to the DLL is needed?  

 

Sounds like you are looking at "U3 Multiple IO Example.vi" which uses the LabVIEW utility VI "AddS-Go-Get.vi" (AGG).  AGG uses a loop that calls AddRequestS for each request, makes one call to GoOne, and then calls GetNextResult to read all results.  AddRequest and GetResult are just driver operations, so take relatively no time.  On the call to GoOne the requests are grouped into as few of low-level packets as possible, sent to the device, and the response(s) read, so only the GoOne call takes noticable time.  So this is a very efficient technique.

 

You could replace "AddS-Go-Get.vi" with "LJUD_eAddGoGet.vi".  This does the same thing in a single call to the DLL.  The time will be the same either way, but I can think of a couple minor differences:  1. Threading related issues could be avoided by having a single call to the DLL rather than multiple,  2. Error handling is simpler with the multiple call technique and acts more like traditional LabVIEW error handling.

 

 

 

 

Why do some calls to the DLL require ASCII text commands (OpenLabJackS for axample) , while others require the text commands be converted to an I32 (using StringToConstant)?   

 

In a language like C it just reads in the header file so you can use strings in code but they are passed as numbers as defined by the header file.  For languages that can't read the header file, it might be more convenient to pass the strings from the header file so many functions have alternate versions.  The eGet() docs have a good description of this:

 

http://labjack.com/s...ers-guide/4.2.3

 

In the case of the LabVIEW-specific utility function "AddS-Go-Get.vi", there is only one version with the single "S", meaning that IOType is passed as string.  This is the most common use, but sometimes when you use the iotype putconfig or getconfig then the channel is a special channel and you usually want a string.  We have not made a "AddSS-Go-Get.vi" (no particular reason I can think of), so you need to use StringToConstant to convert the special channel strings to numbers.

 

The other place I see this happening is if rather than the utility function you used the DLL call "LJUD_eAddGoGet.vi".  Many languages can't pass an array of strings, so we never made "LJUD_eAddSGoGet.vi" or "LJUD_eAddSSGoGet.vi".



#3 joeqsmith

joeqsmith
  • Members
  • 9 posts

Posted 01 October 2014 - 07:11 AM

You could replace "AddS-Go-Get.vi" with "LJUD_eAddGoGet.vi".  This does the same thing in a single call to the DLL.  The time will be the same either way, but I can think of a couple minor differences:  1. Threading related issues could be avoided by having a single call to the DLL rather than multiple,  2. Error handling is simpler with the multiple call technique and acts more like traditional LabVIEW error handling.

 

The eAddGoGet looks good.  I'll try it out.  I have not played with it too much but so far it seems fairly easy to use.   

 

Is there a document that provides details about the hardware?    Specifically, I am interested in knowing what if any protection is on the inputs.   I am also interested in what you have for filtering on the analog inputs.   If there is nothing, are there pads on the board to add at least a single pole RC or something?  

  

Can the OEM version be purchased in singles?   Is the only thing missing besides the case and harness, the connectors?

 

Thanks for your help.



#4 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 01 October 2014 - 08:28 AM

The eAddGoGet looks good.  I'll try it out.  I have not played with it too much but so far it seems fairly easy to use. 

 

Attached are a couple U6 examples that will get you going.

 

 

Is there a document that provides details about the hardware?    Specifically, I am interested in knowing what if any protection is on the inputs.   I am also interested in what you have for filtering on the analog inputs.   If there is nothing, are there pads on the board to add at least a single pole RC or something?  

 

All I/O are protected with diodes to the applicable power rails that clamp any voltages beyond the rails, and further have series resistance that limits the current through those diodes.  The overvoltage limits for different I/O are specified in Appendix A:

 

http://labjack.com/s...uide/appendix-a

 

The resistance on analog inputs reacts with the input capacitance to create a low-pass filter, but the -3dB point is generally 2x-4x the max sample rate of the device, so on the U3 I would estimate 100kHz to 200kHz.  Perhaps lower on the high-voltage inputs of the U3-HV because they have very large input resistors ( ... but also lower capacitance).

 

There are no pads available to install input caps for filtering.  This would not be the best spot anyway as you would have to think about possible effects on the ADC conversion process such as settling time and oscillation.  I recommend you use an LJTick-Divider (with low-voltage analog inputs FIO/EIO on the U3) as you can add caps to the input there and then it buffers the output signal going to the U3 inputs:

 

http://labjack.com/s...vider/datasheet

 

 

Can the OEM version be purchased in singles?   Is the only thing missing besides the case and harness, the connectors?

 

Yes, OEM versions can be purchased at any quantity.

 

The OEM versions have all electronics ... they are just missing the case and most through-hole components.

 

http://labjack.com/s...sers-guide/2.12

 

The picture shows and old version that had a buzzer.  I will make a to-do here to get that updated.

.

.

.

Attached Files



#5 joeqsmith

joeqsmith
  • Members
  • 9 posts

Posted 01 October 2014 - 10:11 AM

Thanks for the example.  Did not find one in the U3 area and was not able to find enough details in the document how to get it working.  

 

LJ_ERROR _stdcall eAddGoGet ( LJ_HANDLE Handle,
long NumRequests,
long *aIOTypes,
 

Do a search for aIOTypes in the document yeilds nothing....

 

With the U6 example you provided, it was pretty simple to get it working on the U3. 

 

 

Do the higher end units have the buffered front end on them and if so, is that part of the layout documented so users can change it as needed?   How close can you run to the rails with the part you are using?



#6 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 01 October 2014 - 12:35 PM

 

 

... a search for aIOTypes in the document yields nothing....

 

eAddGoGet is the equivalent of doing Add-Add-Add-...-Go-Get-Get-Get-..., so you pretty much just need to pass arrays of the things you would pass to a single AddRequest, which are generally IOType, Channel, and Value:

 

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

 

http://labjack.com/s...ers-guide/4.2.5

 

 

aIOTypes is just an array of IOTypes:

 

http://labjack.com/s...ers-guide/4.2.4

 

 

So what IOTypes do you use, and if Channel/Value are not obvious for an IOType then what do you pass for them?  Pseudocode Section 4.3 is the best place for that info:

 

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

 

 

 

 

Do the higher end units have the buffered front end on them and if so, is that part of the layout documented so users can change it as needed?

 

The U6/T7 have an instrumention amp built-in, but it is behind the mux, not 1 per channel:

 

http://labjack.com/s...rdware-overview

 

In order to not have to think about high source impedance and capacitance, you want front-end per-channel buffers, but there are downsides to such circuitry also.  Among them are higher cost, higher power, and errors that are unique to each channel.

 

 

How close can you run to the rails with the part you are using?

 

 

I'm not sure which device & part you are asking about here.



#7 joeqsmith

joeqsmith
  • Members
  • 9 posts

Posted 01 October 2014 - 04:34 PM

>>> Pseudocode Section 4.3 is the best place for that info:

 

That's what I was looking for.  Your example was differential.  I seem to have it all working now code wise.

 

>>>I'm not sure which device & part you are asking about here.

 

I was wondering what op-amp was used and what you use for a supply. 

 

Is there a way to program the filter for the timer inputs?   I assume that the filter is done in software.



#8 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 02 October 2014 - 07:52 AM

 

 

Your example was differential.

 

The IOType LJ_ioGET_AIN is for single-ended readings only.  The IOType LJ_ioGET_AIN_DIFF can be used for single-ended or differential ... set negative channel to 199 for single-ended.

 

 

 

 

I was wondering what op-amp was used and what you use for a supply. 

 

The U6/T7 use an instrumentation amplifier.  See Section 2.6.5 for information about the supply rails and signal range:

 

http://labjack.com/s...ers-guide/2.6.5

 

 

 

 

Is there a way to program the filter for the timer inputs?   I assume that the filter is done in software.

 

I can't think of a "filter" associated with the U3/U6 timers (or DIO-EF on the T7), so not sure what this means.



#9 joeqsmith

joeqsmith
  • Members
  • 9 posts

Posted 03 October 2014 - 08:17 AM

I can't think of a "filter" associated with the U3/U6 timers (or DIO-EF on the T7), so not sure what this means.

 

 

These two sections mention it.

 

2.8.1 .3 - Input: Mechanical Switch Closure
2.9.1.6 - Firmware Counter Input With Debounce (Mode 6)

 

But you have an example that passes values to eTCConfig, aTimerValues for the filter.  So I guess this answers my original question.    

 

aTimerValues – An array where each element is specifies the initial value for that timer. For the U3, this array must always
have at least 2 elements.

 

The comments don't say what is happening or even that it is somehow related to a filter function.   Does the filter's timer reset for every state change detected?   

 

 

 

 

 

 

 



#10 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 03 October 2014 - 08:40 AM

Section 2.8.1.3 mentions that mechanical switches will bounce when switched, and thus create multiple edges rather than just one.  One of the techniques it mentions for dealing with this is using the timer mode "Firmware Counter Input With Debounce".  Debounce is a standard industrial term for dealing with switch bounce.

 

http://labjack.com/s...s-guide/2.8.1.3

 

 

Section 2.9.1.6 describes the debounce mode including a couple key things.  1:  The value you pass for Timer Value specifies debounce period in 16 ms increments according to the shown formula.  2:  The 4th paragraph describes that the debounce period is a time during which edges are ignored.

 

http://labjack.com/s...s-guide/2.9.1.6

 

 

BTW:  The T7 has new logic options for debouncing that work even better:

 

http://labjack.com/s...ounter-debounce



#11 joeqsmith

joeqsmith
  • Members
  • 9 posts

Posted 03 October 2014 - 01:05 PM

Does the counter reset for every state change?  The document does not explain it.



#12 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 03 October 2014 - 01:13 PM

Resetting the count to 0 is explained in the last paragraph of 2.9.1.6.  To reset the count you write a Timer Value of 0.



#13 joeqsmith

joeqsmith
  • Members
  • 9 posts

Posted 03 October 2014 - 02:40 PM

Assume this mode is enabled with a value of 1, meaning that the debounce period is 16-32 ms and negative edges will be counted. When the input detects a negative edge, it increments the count by 1, and then waits 16-32 ms before re-arming the edge detector. Any negative edges within the debounce period are ignored. This is good behavior for a normally-high signal where the switch closure causes a brief low signal (Figure 2-10). The debounce period can be set long enough so that bouncing on both the switch closure and switch open is ignored.

Writing a value of zero to the timer performs a reset. After reset, a read of the timer value will return zero until a new edge is detected. If a timer is reset and read in the same function call, the read returns the value just before the reset.

 

 

If understand this correctly, if there is a glitch that is long enough to be detected it will be counted.   It appears that the counters detect pulses in the 100KHz range, so I assume a 10uS glitch would be detected.    



#14 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 06 October 2014 - 09:56 AM

The hardware counters work for input frequencies up to 8 MHz (Appendix A), but Firmware Counter with Debounce is a timer mode (Mode 6) so is limited to 30k edges/second:

 

http://labjack.com/s...ers-guide/2.9.2

 

By glitch I assume you mean an unwanted edge, which is a transition from logic-high to logic-low, or vice-versa.  Bounce would be the most likely cause, and the cause we can plan for an ignore.

 

Say you have a switch that is normally open, you know that when an event occurs it stays closed for 100ms at most, and you know that events are at least 500ms apart.  I would set TimerValue=12 to get a debounce period of ~200ms.  Whenever the switch closes the U3 will count that initial falling edge, but will ignore any edges after that for 200ms so any bounce that occurs during the close or open will be ignored.  After the 200ms debounce timeout the timer will start looking for a new falling edge again.

 

Say you have a switch that closes-opens with 50% duty-cycle at frequencies from 10Hz to 1 Hz.  You know that this switch bounces for up to 10ms max on both the close and open.  Say you set the debounce timeout to 20ms and the switch is switching at 10Hz.  When the switch closes the falling edge is counted and the bounce is ignored, but 50ms later when the switch opens the bounce creates another falling edge that is counted.  Say you set the debounce timeout to 520ms.  This would properly debounce the switch at 1 Hz because the close and open are both during the timeout, but when the switch is going at 10Hz you would miss actual closures.  The debounce timer will not work for this on the U3, and this is where you can see the extra intelligence of the T7 debounce options will work.



#15 joeqsmith

joeqsmith
  • Members
  • 9 posts

Posted 06 October 2014 - 07:47 PM

The way you describe it, any noise could cause the unit to trigger.   Using your Test Panel,  I tried it with the firmware debounce mode.  Sending a burst of 10 pulses at 5MHz every second, sure enough the value increments one count every second.  

 

It would be better if the input had to remain stable for the debounce time before it becomes stable.  Maybe this can't be done with the design you have.  

 

If it becomes a problem, I'll attempt to add some sort of external filter. 



#16 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 07 October 2014 - 08:19 AM

Yes, this firmware timer mode is meant to debounce edges and is not necessarily a filter.  If you are worried about EMI or other transients inducing false edges on the line, then you will have to add something.  Often a stronger pull-up is a good idea ... consider a 4.7k or 10k pull-up to VS rather than just relying on the internal 100k pull-up to 3.3V.  Beyond that a simple RC on the digital input could easily get rid of fast induced transients.

 

Your idea for a debounce or filter where the line must stay in a particular logic state for some amount of time to register a count does sound good for some applications.  We will look at this for the T7, but doubt we can do anything on the U3/U6.



#17 joeqsmith

joeqsmith
  • Members
  • 9 posts

Posted 08 October 2014 - 02:51 PM

I can't take credit for that way of filtering. 

 

It would be pretty cool for you to provide users with hooks into your software/hardware.   Not knowing anything about your designs, say you have an FPGA, you would allow the users to install their own designs.  Or say you use a PIC, you have hooks allowing the user to upload some custom routines.  

 

All in all, I am pretty happy with the U3.  It's been real stable and is plenty fast for what I plan to do with it.   Made a little video of it in action.

 



#18 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 09 October 2014 - 07:06 AM

Nice looking app.  I have a Lenovo tablet that looks similar and it is slick because it runs full-blown Windows 8.

 

We dabbled in providing user scripting on the U3/U6, but the processor is too limited (speed, memory, etc.) and we wound up with something that was too limited and too hard to support.  On the new T7, though, we do provide Lua scripting, and will promote it once the functionality, tools, and examples are more complete:

 

http://labjack.com/s...ts/t7/scripting

 

New lower-cost devices in the T-series family might also support this feature.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users