05-25-2011 05:28 AM
05-25-2011 04:53 AM
For starters, you create a new DaQMX-tast for each read, just wire through from the first one you created.
You also create a new task every loop, create it outside.
This sounds like a good idea indeed! I will first try it in another program so I do not mess this one up.
Since you have well defined frames, it's a good candidate for a state machine.
Is this not the way to make a state machine in LabVIEW ? Without all the fuss of cases loops and so on? ( I used too program in VHDL so this looks like it does the same)
Now that I got some people's attention, I seem to get a lot of noise into my DAQmx analogue measurement, about 20mV.
I have tested it, the DAQmx is not broken and the cables are fine to. On the forums I find other people with the same problem but not any solution to it, nor common cause.
Thanks for the help so far.
Stieve
05-25-2011 06:15 AM
Basic State Machine modification, it'll get you started. 🙂
/Y
05-25-2011 06:46 AM
Wauw! Thanks for the effort !
I must admit, it does not work the way it should. Probably because you do not have the full perspective on the project.
The idea behind it looks very good and professional. Atleast if you compare it with my program.
I will most definitely keep it as an example in the future.
Any ideas maybe why I get a +20mV noise value on my DAQmx readings ?
05-25-2011 07:17 AM
Not surprising, your old code had some administration commands which are now left in the 2nd loop, you can create another state or add them to the End state, or similar.
Your old X-case isn't implemented as of yet, but it shouldn't be much tinkering needed to get stuff to work.
Why you get the noise i cannot help you with, but if you're lucky the constant DAQ openings created some interference. 🙂
/Y
05-25-2011 07:51 AM
Indeed, my guess is that the 2 administration loop gives a bit of a jitter.Because 2 while loops never run at the same time.
I am working with filp flop and other things, so timing is absolutely crucial.
And i didn't notice that the the old other case was out, i'll see into that.
Main thing is that I got a manually version if the flip flop's need to be resetted and I got a V1.0 version that works perfect.
At the moment I am working on a V1.2 and your VI will surve as an example for that.
The noise is probally caused by the constant DAQ openings, it is the only thing that makes sence. On thursday my interface PCB that i designed arives,
if that does not help at all I'll contact the forum again.
thanks for the great help so far!
Stieve
05-25-2011 07:53 AM
What is the expected fullscale reading of the channels where you have the 20 mV noise (to see how many bits of resolution 20 mV represents). If you use the Measurement & Automation (MAX) utility to look at the signals, do you see the noise? If so, can you see any periodicity (underlying frequency), or any repetition, or does it look like truely random noise. Low level noise is always an issue with any DAQ, and comes from a very long list of causes. How signals are coupled, how the signal returns are grounded, cable layout, lab or factory electrical noise (large motor controllers can be amazingly noisey), etc., etc., etc. (I'm too fond of "The King and I"!)
05-25-2011 08:01 AM
The old DEC stuff used switching power supplies so 20mV of ripple on the logic signals was nothing. Of course I assuming you are using the DEC supplies to power the gear.
Ben
05-25-2011 08:10 AM
Ah, been a while since I looked at DEC, Data General, etc. As Ben says, if these are logic signal they can be pretty noise, and don't actually effect logic operations if your 1's and 0's are in the legitimate ranges, there is a big "buffer" zone around each level, "forbidden zones", that were defined as invalid levels. A TTL high was generally anything from +2 to +5V, a low from +0.8 to 0V, anything between was invalid (and could have odd effects). Other technologies than TTL had different level requirements, but they all had a buffer between a valid low and a valid high.
05-25-2011 08:20 AM
If I remeber, I'll consult the Q-Bus manual I have at home to se what the real spec was.
Ben
PS Provided I can find it! Last seen next to the VAX-VMS Internals and Data Structures but where did they get moved too?
05-25-2011 08:30 AM
@LV_PRO
My expectations depend on the input. Octally 200 is 1.250V, octally 40 is 313mV and so on. At the moment I should have a 313mV output. If I measure on the IC output or the flatcable pin (with respect to the ground) I have between 312mV and 319mV randomly, these small differences are acceptable. But when I connect the AI from my DaQmx 6259 I measure between 330mV and 340mV randomly, these differences are far from acceptable.
I have tried looking with the MAX tool and calibrating the DAQmx but it didn't work. I am measuring with respect to the ground also.
Probably the noise is generated by the digital out signals that I am constantly sending out, but I am not sure of that. The cable that I am using is SHC68-68-EPM so my guess is that is fine aswell.
@Ben
Indeed, my power for the setup comes from the DEC and I am just using ordinary NPN transistors instead of the 8838 bus transceivers because my PCB will not arrive before Thursday. The power for the PXI system chassis is just plugged into the outlet.These transistors are only used as input switch and have nothing to do with the analogue feedback.
________________________________________
I have tried measuring the signals from a lab voltage source and this worked perfectly. Within a range less then 1mV so the Daq itself is fine, the labview settings are fine and the cable is fine to.
There are not large engines close to me, only a X-ray measurement dive but this is turned off also.