U6 and LJTick_DAC
Posted 13 June 2010 - 03:36 AM
Posted 16 June 2010 - 10:45 AM
I've a LJTick DAC connected on my U6, wich works fine with the LJTickDAC utility from LabJKack (DAC on FIO0 and FIO1).
When I try to drive the DAC with the DAQFactory example downloaded from LabJack website (DAC on FIO4 and FIO5), the DAC don't work and I get an error message in the command window :
"(...) Communication error with LJTDAC module, wrong number of ACKs received".
The problem remains if I change the LJTDAC slot.
Any idea of what's wrong ?
Can you please try the attached example and write back with the result along with your firmware and UD driver version? Both version numbers can be found in LJControlPanel.
Edit: I think there may have been an issue with the channel event code that has been corrected with this example. Also, to test it, please attach the LJ-TickDAC to the FIO0/1 block. Thanks and I apologize for the confusion -- LabJack Support
Posted 17 June 2010 - 09:33 PM
Posted 18 June 2010 - 08:34 AM
Posted 19 June 2010 - 02:21 AM
Posted 22 June 2010 - 09:58 AM
DAQFactory is working again.
I tried the file .ctl you sent, just adding a call to errorhandler in the event sequence of DAC_A4 channel (see attached).
Each time the DAC_A4 event is called, I get an error message :
"Error occured on io type : 506, channel type : 5125, code : 69 : Communication error with LJTDAC module , wrong number of ACKs received"
UD driver : 3.15,
Firmware : 1.130
Bootloader : 6.150
Hardware : 2.000
I did some digging and it looks like you need to upgrade your driver to our 3.20 beta. Please visit this address for instructions: http://labjack.com/s...dows-ud/beta-ud. I also noticed that our testing U6 has a newer firmware (1.50) but I think you should be fine. However, if the program still does not work properly, go to Start > All Programs > LabJack > LJSelfUpgrade to change it. Lastly, I cleaned up the example that I provided for you earlier to use the FIO2/3 block (twos are often easier to find than zeros). Please try using the LJTickDAC on that block instead.
Thank you for your patience,
Posted 23 June 2010 - 12:47 PM
Posted 19 February 2014 - 03:07 PM
Im doing something similar in DAQfactory express and would like to use the U6Pro to control the LJ-DAC on FIO0 & FIO1 pins while also reading 0-5V analogue signals back in on AIN0, AIN1 and AIN2.
Im reading just over 10V on all three analogue inputs where the multimeter says it should be 0.
Can you use the FIO0 and AIN0 at the same time? These appear to have the same channel numbers in DAQfactory though i could be wrong- your webpage only list U3 and U9 for channel number examples.
any help would be greatly appreciated
Posted 19 February 2014 - 04:01 PM
Yes, you can use FIO0 and AIN0 at the same time. In DF you specify an iotype and channel number. So, for example, analog input 0 (AIN0), is different than analog output 0 (DAC0), which is different than digital I/O 0 (FIO0).
Does DF read the analog signals correctly without the LJTDAC stuff? Just open a new CTL and add a AIN channel or two.
Does LJLogUD or the test panel in LJControlPanel read the analog inputs correctly?
Are you measuring with your DMM from AIN0 to GND, while looking at the AIN0 reading on the computer at the same time?
Posted 19 February 2014 - 11:12 PM
I think I have the gist of the differences between AIN, FIO - I have previously been used to the U3 where they are on the same pins.
I have re-checked the AIN values in a new DAQfactory program and they are still reading 10V.
However, when I ran LJControlPanel it registered that there may be a calibration problem (G-0.000248/10.115590) on the high speed (not high res) convertor and that I should contact you guys about it.
Is it possible that this is my problem?
Posted 20 February 2014 - 09:44 AM
That is strange. Connect VS to AIN0 so it should read about 5 volts, and connect GND to AIN1 so it should read about 0 volts. Then run LJLogUD and look at the readings from +Ch=0/-Ch=199 and +Ch=1/-Ch=199 (which is the first two rows by default). Compare the readings with resolution index set to 1-8 or 9-12.
Posted 20 February 2014 - 03:04 PM
After connecting AIN0 to VS and AIN1 to GND the LJlogUD program was able to measure those signals with resolution factor 0-8. At higher resolution settings 9-12 it still measured 10.115590. I tired changing the resolution factor in DAQfactory but this had no effect.
The value of 10.115590 is the same as mentioned in the calibration problem in LJControlPanel. It was reading this value on the first 4 channels and the GND (I cant remember if it was -ve of not). When I checked it afterwards I also noticed that the temperature is reading ~ -750 degC.
Its starting to sound like an electronic fault. Should I try re-loading the firmware? Ive tried the pull USB plug out and replug (my last option).
Posted 22 February 2014 - 10:36 AM
You certainly want to try power-cycling the device (disconnect/reconnect the USB cable and have no other connections to the U6 besides USB and the 2 jumpers for AIN0/1), and re-programming firmware is worth a try, but it sounds to me like your high-resolution converter has been damaged. Contact [email protected] for an RMA so we can check it out.
Posted 16 April 2015 - 03:28 PM
Hello, I am running two LJTick_DAC's on my U6-PRO with DAQ factory...
I seem to get some cross talk, meaning updating a value on the second LJTick_DAC momentarily updates voltage on the first one
I am using the output of a PID look to change the voltage of the two DACs.
The first LJTick_DAC is on FIO4 and FIO5 and the second is on FIO6 and FIO7
I have assigned them individual channel names and numbers in DAQ factory as:
DACA_1, channel 0, DACB_1, channel 1 for DAC 1 on FIO4/5
DACA_2, channel 0, DACB_2, channel 1 for DAC 2 on FIO6/7
In the channel event i have:
Posted 16 April 2015 - 04:00 PM
I would not expect any crosstalk. How are you seeing it? Do you see it on a scope?
Perhaps attach a CTL simplified as much as possible that demonstrates the problem. Or better yet, do you see the problem with LJTDAC_Dual.ctl:
Posted 05 May 2015 - 04:09 PM
I see it by monitoring the voltage output of the DACs with analog inputs on the same lab jack
the DAC outputs are also hooked up to pressure regulators, so for example:
if DACA_1 is set to 10v updating every 0.2 sec this runs the regulator at 100 PSI
if DACA_2 is set to 0v also updating every 0.2 seconds this runs its the regulator at 0 PSI
so when the cross talk occurs i see DACA_1 jump to 0v for 0.2 seconds, and this causes the regulator to vent its pressure that is very obvious
I found a topic on this forum (https://forums.labja...?showtopic=4327) where the issue was fixed by replacing the two eput commands in the channel event with an addrequest and go command in my case:
Posted 06 May 2015 - 08:00 AM
Is this still with multiple loops having similar code? I feel like you have some sort of threading issue:
... actually, your issue might better be described as lack of threading. If the 4 loops execute at the same time, in the same thread, the requests could be mingled such that you don't know the exact order they are all happening. You might need to post on AzeoTech's forum to discuss solutions, but I will send them a message right now to check this topic:
Posted 06 May 2015 - 11:48 AM
yes there are four analogous loops (DACA_1, DACB_1, DACA_2 and DACB_2), however I get missed updates if i only alter one of the variables at a time.
I suppose all four loops are constantly running though...
Posted 06 May 2015 - 12:03 PM
Also as i understand variables in DAQ factory are arrays with a history.
sometimes the DAC will update to the previous array value: DACA_1 for example rather then DACA_1 as the code specifies...
So it misses updates and sometimes updates to the previous point in the array
Posted 10 May 2015 - 10:09 PM
Yes, that definitely sounds like a threading issue, especially if you are updating from multiple threads. You can never predict when the system is going to context switch. It could do it between commands or even in the middle of a command. There is some protection for this, but that protection is more to keep DAQFactory from crashing from a threading issue then solving thread issues in script.
I would recommend combining the four loops into one. It will require a little more logic, but it will eliminate any threading issues.
As for variables, variables do not have history unless you explicitly create a history, which is really just an array, either by addressing as an array:
x = 3
or by using addValue() or append()
global x = 4
x = 3
results in x just holding 3. Subsequently doing:
will print nothing because x is still a scalar.
This is different from output channels, which will automatically build a history.
That all said, even the variable problems you are having are almost certainly thread related.
Posted 11 May 2015 - 11:49 AM
I tried combining the loops into one. instead of using four channels I put code in the event of a single channel to control all four DACs (see below)
Posted 11 May 2015 - 01:31 PM
I'm not sure. There is likely other stuff going on in your app that's not apparent in your posts. I would start by creating a blank application. Don't create any channels, just declare four variables. Then create a script to update the four dacs from those four variables, basically the script you posted. It should work perfectly. Once you've proven that it can work, you can go through your app and figure out what's different. Always start simple.
Posted 11 May 2015 - 04:08 PM
I'm pretty sure you want to use a sequence, not event.
Also, you could get some confusion because some of your calls are passing "2" for D# and others are passing "ID".
Posted 13 May 2015 - 03:22 PM
Sorry the "2" vs "ID" thing is a type here, ID is a variable that = 2 in my DAQ factory app.
Sounds like what I haven't done is run the code from a sequence rather than a channel event.
I will give that a go...
Posted 14 May 2015 - 09:01 AM
placing the code in a sequence loop rather than individual channel events works perfectly, and in my complicated multi-functional DAQ factory application.
I run a loop at a frequency of 10 Hz, where DACA_1, DACB_1, DACA_2, and DACB_2 are variables. All four DACs update flawlessly with no cross talk :
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users