Possible LJTDAC Crosstalk

[burt4munger]

The following control file is the result of paring down a large control panel application until I have just the components that appear to break. I am using two LJ Tick DACS and three timer channels on a Labjack UE9, DAQFactory 1579A build 1583. Reading the timer channels changes the output of one of the DACs. The setup is described in the file main page, and opens with the problem displayed (when you attach a multimeter). Changing the timer channel read timing to 0 makes the problem go away.

This is fairly urgent; I finally just isolated this and have to install the application next week. Since the DAC outputs control very large motors, fluctuating values are something of a problem! I'm around this weekend, and in times past I've seen some weekend response, so if this is one of those weekends, hooray! Otherwise I'll watch Monday for an update. This might actually be a Labjack firmware problem, so I'll post there as well.

Thanks,

Burt.

LJTDAC_Cross_Talk_Test.ctl

[AzeoTech]

I'm afraid you are right and this is likely a LabJack problem. The DAQFactory LabJack driver is largely a pass through to the LabJack UD, so problems are usually on their side. The exception is really only streaming, where we handle the callback from the UD. I will also email the LabJack folks to see if they'll respond as well on a weekend.

That said, my first thought is that you have a pin conflict. I can't guarantee this, but I know they did some stuff where they offset the timer pins to 4, meaning timer 0 is actually on pin 4. Its why all the samples in the DAQFactory-LabJack app guide use pin 4. Older firmware uses pin 0, but newer stuff uses pin 4. Anyhow, you might try using this line:

AddRequest (ID, LJ_ioPUT_CONFIG, LJ_chTIMER_COUNTER_PIN_OFFSET, 4, 0, 0)

(replacing ID with your ID) to force the timers onto pin 4. Then move the TicDacs to pin 0-1 and 2-3. This would eliminate any ambiguity.

[burt4munger]

Interestingly enough, the very line for pin offset that you've recommended below is the one I'm using, and in the LJ forum, they suggested that it would cause a problem. However, the timers do work with that setting.

Using that pin offset command, my timers are on FIO0-3, and the DACS are on FIO4-7. Your post implies that the pin offset 4 would put the timers on FIO4-7, leaving FIO0-3 for the DACS. I'm beginning to wonder how my configuration works at all; there seems to be some confusion, somewhere, about what the pin offset does.

I detected a problem with my test file, the posted one was trimmed a little too aggressively, so I've attached an updated one that will work from power up of the UE9; the other one doesn't.

from my post on LJ Forum:

I do have current versions of UD driver, of DF, and the firmware as reported by LJSelfUpgrade.

I'll try changing the pin offset command, but I'll have to set up a timer input to see if the timers still work after that. They definitely work as is.

Reading them definitely causes the problem, any read of any timer channel through DF will cause it. I've tried various permutations to see if it was timer 0 or 1 in particular, guessing that they might have some internal use clocking the serial communications with the DAC. It would be an interesting test to see if a sequence code read has the same effect, so I'll give that a try as a possible work around, but this configuration "should" work.

I realized that the file that I uploaded was trimmed a bit too far, it is missing some important initialization such that if I do a cold start power cycle on my UE9 that file doesn't set the DAC at all. So here is an updated test file that will show the problem when loaded from scratch.

Thanks to both companies by the way, for replying on the weekend. Very cool.

LJTDAC_Cross_Talk_Test_1.ctl