PWM Control over 2 LJ's

[mkelly]

Background:

2 Labjacks running LJTick-RelayDriver boards.

Previously operational using this code structure to control 4 relays on labjack ID=0. Modified from the example

// configure PWM timer:
//Set the timer/counter pin offset to 4, which will put the first timer/counter on FIO4.
AddRequest (ID,  LJ_ioPUT_CONFIG, LJ_chTIMER_COUNTER_PIN_OFFSET, 4, 0, 0)

// use system clock so works on U3 and UE9:
AddRequest(ID, LJ_ioPUT_CONFIG, LJ_chTIMER_CLOCK_BASE, LJ_tc1MHZ_DIV, 0, 0)
AddRequest(ID, LJ_ioPUT_CONFIG, LJ_chTIMER_CLOCK_DIVISOR, 15, 0, 0)

//Enable 4 timers.
AddRequest(ID, LJ_ioPUT_CONFIG, LJ_chNUMBER_TIMERS_ENABLED, 4, 0, 0)

//Configure Timer0 as 16-bit PWM.
AddRequest(ID, LJ_ioPUT_TIMER_MODE, 0, LJ_tmPWM16, 0, 0)
AddRequest(ID, LJ_ioPUT_TIMER_MODE, 1, LJ_tmPWM16, 0, 0)
AddRequest(ID, LJ_ioPUT_TIMER_MODE, 2, LJ_tmPWM16, 0, 0)
AddRequest(ID, LJ_ioPUT_TIMER_MODE, 3, LJ_tmPWM16, 0, 0)

//Set the PWM duty cycle.
AddRequest(ID, LJ_ioPUT_TIMER_VALUE, 0, 65535 * PWMWidth / 100, 0, 0)
AddRequest(ID, LJ_ioPUT_TIMER_VALUE, 1, 65535 * PWMWidth2 / 100, 0, 0)
AddRequest(ID, LJ_ioPUT_TIMER_VALUE, 2, 65535 * PWMWidth3 / 100, 0, 0)
AddRequest(ID, LJ_ioPUT_TIMER_VALUE, 3, 65535 * PWMWidth4 / 100, 0, 0)

//Execute the requests.
GoOne(ID)
ErrorHandler(ID)

Problem:

Adding the 2nd labjack to also output a PWM signal akin to labjack 0.

My initial thought was to add another ID (global ID2=1) and then duplicate the configuration prior.

// configure PWM timer:
//Set the timer/counter pin offset to 4, which will put the first timer/counter on FIO4.
AddRequest (ID,  LJ_ioPUT_CONFIG, LJ_chTIMER_COUNTER_PIN_OFFSET, 4, 0, 0)
AddRequest (ID2,  LJ_ioPUT_CONFIG, LJ_chTIMER_COUNTER_PIN_OFFSET, 4, 0, 0)

// use system clock so works on U3 and UE9:
AddRequest(ID, LJ_ioPUT_CONFIG, LJ_chTIMER_CLOCK_BASE, LJ_tc1MHZ_DIV, 0, 0)
AddRequest(ID, LJ_ioPUT_CONFIG, LJ_chTIMER_CLOCK_DIVISOR, 15, 0, 0)
AddRequest(ID2, LJ_ioPUT_CONFIG, LJ_chTIMER_CLOCK_BASE, LJ_tc1MHZ_DIV, 0, 0)
AddRequest(ID2, LJ_ioPUT_CONFIG, LJ_chTIMER_CLOCK_DIVISOR, 15, 0, 0)

//Enable 1 timer.  It will use FIO4.
AddRequest(ID, LJ_ioPUT_CONFIG, LJ_chNUMBER_TIMERS_ENABLED, 4, 0, 0)
AddRequest(ID2, LJ_ioPUT_CONFIG, LJ_chNUMBER_TIMERS_ENABLED, 1, 0, 0)

//Configure Timer0 as 16-bit PWM.  
AddRequest(ID, LJ_ioPUT_TIMER_MODE, 0, LJ_tmPWM16, 0, 0)
AddRequest(ID, LJ_ioPUT_TIMER_MODE, 1, LJ_tmPWM16, 0, 0)
AddRequest(ID, LJ_ioPUT_TIMER_MODE, 2, LJ_tmPWM16, 0, 0)
AddRequest(ID, LJ_ioPUT_TIMER_MODE, 3, LJ_tmPWM16, 0, 0)
AddRequest(ID2, LJ_ioPUT_TIMER_MODE, 0, LJ_tmPWM16, 0, 0)

//Set the PWM duty cycle.
AddRequest(ID, LJ_ioPUT_TIMER_VALUE, 0, 65535 * PWMWidth / 100, 0, 0)
AddRequest(ID, LJ_ioPUT_TIMER_VALUE, 1, 65535 * PWMWidth2 / 100, 0, 0)
AddRequest(ID, LJ_ioPUT_TIMER_VALUE, 2, 65535 * PWMWidth3 / 100, 0, 0)
AddRequest(ID, LJ_ioPUT_TIMER_VALUE, 3, 65535 * PWMWidth4 / 100, 0, 0)
AddRequest(ID2, LJ_ioPUT_TIMER_VALUE, 0, 65535 * PWMWidth5 / 100, 0, 0)

//Execute the requests.
GoOne(ID)  
GoOne(ID2)
ErrorHandler(ID)
ErrorHandler(ID2)

But this does not appear to have any effect on the 5th output channel.

Is this the right approach? Would i be better to have a seperate sequence for setting up the 2nd labjack?

[AzeoTech]

First, if you are using 2 LabJack's, you cannot use ID = 0. ID = 0 means first found in DAQFactory.

That is most likely your problem. But you also should do your errorhandler() right after the goOne().

[mkelly]

I have my LJID's set as 1 and 2 from LJCP. Daq Factory ignores these settings and sets the device ID to 0 and 1.

For my channel setup I have D# set to 0 and 1 and these work fine. If I set a D# to 2 DAQFactory says it cannot see the device.

[AzeoTech]

DAQFactory doesn't ignore anything. In fact, all the LabJack stuff is passed through to the LabJack UD driver, with the exception that DAQFactory will convert an ID of 0 to -1 (first found). You should NEVER use ID 0 on a LabJack or D# 0 in DAQFactory if you are using more than one LabJack. The fact that it worked is a fluke and it may not remain working. If D# = 2 doesn't work then you should figure out why. Note that if you use an D# of 0 in DF and then switch and try and use the ID directly it won't work without restarting DAQFactory. This is because the LabJack UD driver, when you request First Found (D# = 0), opens a connection to the LabJack, in your case the one with ID=2. When you then go and change it to D# = 2 without restarting, the LabJack UD driver already has that LabJack open, and thus says it can't be found because, in fact, you are already communicating with it through a different ID (first found). Note that this a feature of the LabJack Driver, not DAQFactory.

Set all your D#'s to 1 and 2, save your document and restart.

[mkelly]

DAQFactory doesn't ignore anything. In fact, all the LabJack stuff is passed through to the LabJack UD driver, with the exception that DAQFactory will convert an ID of 0 to -1 (first found). You should NEVER use ID 0 on a LabJack or D# 0 in DAQFactory if you are using more than one LabJack. The fact that it worked is a fluke and it may not remain working. If D# = 2 doesn't work then you should figure out why. Note that if you use an D# of 0 in DF and then switch and try and use the ID directly it won't work without restarting DAQFactory. This is because the LabJack UD driver, when you request First Found (D# = 0), opens a connection to the LabJack, in your case the one with ID=2. When you then go and change it to D# = 2 without restarting, the LabJack UD driver already has that LabJack open, and thus says it can't be found because, in fact, you are already communicating with it through a different ID (first found). Note that this a feature of the LabJack Driver, not DAQFactory.

Set all your D#'s to 1 and 2, save your document and restart.

When I was adding my 2nd labjack I did set it up as 1 and 2 in DAQFactory. However this never worked. I removed all traces of ID 0 and it still refuses to recognize both devices. I just see "Labjack Device #2 error: Labjack not found" My ID# has _never_ been 0.

Here's my steps that aren't working which are exactly as you specified.

Verified that no trace of ID 0 in my channels, and sequences

Verified labjacks are correctly IDing in LJCP

Just for experiment I switched which one was 1 and 2

Open DAQF ctl file only to get an error

I've tried other things like using channels 2 and 3. The only way I'm able to read the values from the 2nd labjack is by setting it's D# in DAQF to 0. Then it can read the values. It does not see the LJID it seems.

[AzeoTech]

So, when you switched the ID's did the one that didn't work switch too, meaning that the same physical LabJack would always fail?

You really don't want to use D# 0 if you have more than one LabJack. For all you know, when you use D# 0 and 1 you are connecting to the same LabJack (despite what I said). I'm going to have to refer this one to the folks at LabJack. As I said, we simply pass these ID's through to the LabJack UD, so any problems are in their court.

That said, I'd make sure you have the same firmware on both LabJacks and that you are running the latest UD. Also, can you create separate documents communicating with each LabJack on its own?

[mkelly]

It is the same Labjack failing to communicate. I live in the same city as labjack so I'll see about swapping the one I have

I didn't really want to use ID 0 but am on a tight schedule and can't afford much downtime. I did it as a "I have to have this thing working today" last resort.

The LJ's are both on the most recent version. The only difference is the bootloader of one is slightly older than the other. I'm voting the one is just misbehaving. So I'll swap that out before I try the seperate documents cause I'm not hopeful that will solve the issue.

[AzeoTech]

Yeah, sounds like a hardware issue. That's fine if ID = 0 works for you, but its my job to warn you that its very unpredictable and that its possible that you'll end up connecting to the wrong device under ID #0 depending on how the operating system enumerates the devices. My guess is that it would be consistent as long as you didn't move the devices to different USB ports, but I'm not completely sure.