Posted 07 November 2012 - 02:35 PM
Posted 07 November 2012 - 04:09 PM
Not much to go on. Can you send any detail about the device? Can you post a short data file from LJStreamUD?
I have a signal from a piece of electronics about which I know very little. I tried using LJStreamUD to acquire data and to look at this signal and I was observing fairly consistent voltage changes of 5V. Is it likely I am seeing a digital signal?
See Section 3 about data rates:
I ran into the issue of sampling rate while trying to acquire analog data. If I acquire digital data is there a sampling rate? What would be the easiest way to acquire digital data?
As for digital data, it depends on what type of signal it is and how you wind up acquiring it. If you just sample it, then stream mode is the fastest way. If it is some sort of serial data, then there might be a different way.
LabVIEW is a full-blown programming language. If you don't know LabVIEW, you will have to learn quite a bit, and the tutorials from NI are a good place to start. If you know another programming language such as C or VB, it is easier to learn LabVIEW.
I have no experience with Labview but I have downloaded a student copy. I have opened the U3 eDI example but I would prefer something that can save data to a text file.
Posted 07 November 2012 - 06:53 PM
Posted 08 November 2012 - 08:43 AM
Posted 08 November 2012 - 08:02 PM
Posted 08 November 2012 - 10:43 PM
Posted 09 November 2012 - 08:06 AM
For buffer overruns, does it happen right away or does the program do multiple iterations successfully and return data for some time? Do you see the "UD Backlog [%]" growing while you stream? Can you send a related screenshot so we can see the backlog and all your settings?
I have tagged someone else on the crashing issue, but try UD V3.30 and another thing to try is different USB hubs:
Posted 09 November 2012 - 08:20 AM
Posted 09 November 2012 - 05:50 PM
With the VI as I progressively increase the scan rate I eventually see buffer over-runs as expected. There is likely not much to be done there except try the suggestions on your webpage on sampling/scan rate. It does seem to me that having Labview run the VI is going to take CPU effort and will make it more difficult to sample at a higher rate.
This is where it would be nice to have the executable working, I assume this might alleviate the buffer over-run issue to some degree. Sometimes it works but this is rare and I have seen no trend indicating what causes the problem. It just worked a moment ago with the default settings but when I tried to close it it crashed again.
Usually if it crashes (other than when I close the program, it seems to crash pretty well every time I close it) it crashes immediately upon starting to stream with error 1001.
I will try the driver you linked to.
A 1001 error is typically caused by some sort of memory access violation that the driver detects. Normally this is caused by code someone makes where they don't make an array large enough, pass it properly, etc. However, LJStreamUD should be doing everything properly there, thus the error is a little strange. Can you give us as specific as possible information about when it occurs? i.e. does it occur right when you start up, immediately when you start the stream, after a second of streaming, is it dependent on how fast you stream, etC? Also, is your LabView version 32-bit or 64-bit when you run the .vi directly? Do you have more than 4 gb of ram?
Posted 07 April 2013 - 06:17 PM
Posted 07 April 2013 - 06:28 PM
Posted 08 April 2013 - 06:34 PM
I just re-read the last comment.
I could start streaming at 500 Hz. When I stopped and restarted at 5000 Hz (1 channel) LJStream UD crashed indicating error 1001.
I closed the program (no other option), restarted it, and changed the scan rate to 5000 Hz before starting the stream. I was able to start and stop the stream. Suddenly LJStream worked fairly well. I went up to 40 000 Hz (without restarting the program) at which point I observed small backlogs (at the other scan rates I tried: 500, 5000, 10 000, and 20 000) I had no backlog.
I had previously tried changing the scan rate to 5000 Hz immediately and observed the program crash.
I just opened the program and the scan rate was already set to 10 000 Hz and it crashed immediately upon trying to start the stream (it has always been an immediate crash) but no no numerical error code was indicated (see screen shot).
We found 1 and only 1 PC in the office that we think has this same issue. The good news is we found a version of the .dll that seemed to work without the error (or perhaps moves the error to the close of the program), the bad news is it was a debug build of the .dll. It is linked in this post: https://forums.labja...o...ost&p=20498
That should work for you (hopefully). We will work on tracking down the root cause of it, but it could take a few days since it doesn't seem to occur with the debug build, and thus we won't have access to all the convenient debugging tools. As long as we can reproduce it though we should be able to fix it.
Posted 25 September 2013 - 01:03 PM
I want to use the U3 HV in Labview 2010 to acquire an piezoelectric accelerometer. In this moment we are now using the LJstreamUD, I have some questions; after 3 days of consulting of user guide in the section 2,3 etc... whit my team, we did not understand:
- what is the function of SCAN RATE(Hz)? In the manual the description it's so scanty.
- what is the function of RESOLUTION? It isn't like manual description in the table 3.2-1, shifting the parameter from 0 (default) to 1, or 2 or 3, we haven't observe mutations, and we would shift from 2500 sample/s to 50000 samples/s.
- How do I match acquired value to timestamp?
n.b.: We have already read the user guide 6 time.
Posted 25 September 2013 - 01:18 PM
1. ScanRate is how many scans you are going to acquire per second. For example, if NumChannels=4 and ScanRate=1000, that means that every 1 ms the U3 will acquire a scan from all 4 channels, and thus the sample rate is 4000 samples/second.
2. I suggest you just use Resolution=0, which means the U3 will automatically adjust resolution as needed. The resolution parameter is seldom used in stream mode with the U3.
3. You know the elapsed time based on 1/ScanRate * ScanNumber.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users