Our full technical support staff does not monitor this forum. If you need assistance from a member of our staff, please submit your question from the Ask a Question page.


Log in or register to post/reply in the forum.

Problem with AM25T in SlowSequence


MatthewBoyd Jan 14, 2015 03:09 PM

I'm getting strange behavior from the following program. The last 2-4 TC_C's read a significantly higher temp., with the number that do changing with the settling time. However, higher settling times do not correlate with less errant readings. It seems like there is a timing or synchronization problem, but I can't figure out where. Any suggestions? I do need to keep the two measurement sets in the main scan and the slow sequence, respectively.

(Note: I've tried adding other AM16/32B measurements in the same SlowSequence, also bounded by SemaphoreGet/Release(2), and I get 7999 or -7999 readings for some of the measurements, also changing with the settling times.)


'CR1000.Std.27

PipeLineMode


Const FullPyrSetl_us = 3000
Const AnalogSetl_us = 3000
Dim AM25TIsInRev = True
Dim FullAM25TInteg = _60Hz


BeginProg

Scan(1,sec,5,0)

SemaphoreGet(2)

AM25T(Var1_mV,1,mV25,1,AM25TDiffCh,-1,AM25TRefTemp_C,MUXClkPort, _
AM25TResetPort,0,AM25TIsInRev,FullPyrSetl_us,FullAM25TInteg,1,0)

AM25T(Var2_mV,1,mV2500,5,AM25TDiffCh,-1,AM25TRefTemp_C,MUXClkPort, _
AM25TResetPort,0,AM25TIsInRev,FullPyrSetl_us,FullAM25TInteg,1,0)

...

AM25T(Var6_mV,1,mV25,6,AM25TDiffCh,-1,AM25TRefTemp_C,MUXClkPort, _
AM25TResetPort,0,AM25TIsInRev,FullPyrSetl_us,FullAM25TInteg,1,0)

SemaphoreRelease(2)

CallTable(AnalogTable)
CallTable(RTDAndTCTable)

NextScan


SlowSequence
Scan(10,sec,0,0)

SemaphoreGet(2)

AM25T(AM25TRefTemp_C,0,mV2_5,1,AM25TDiffCh,TypeT,AM25TRefTemp_C,MUXClkPort, _
AM25TResetPort,AM25TExCh,AM25TIsInRev,AnalogSetl_us,FullAM25TInteg,1,0)

AM25T(TC_C(1),8,mV2_5,12,AM25TDiffCh,TypeT,AM25TRefTemp_C,MUXClkPort, _
AM25TResetPort,AM25TExCh,AM25TIsInRev,AnalogSetl_us,FullAM25TInteg, _
TCMultipliers(),TCOffsets())

SemaphoreRelease(2)

NextScan
EndSequence

EndProg


DAM Feb 5, 2015 05:26 PM

Using the same AM25T in the main scan and the slow sequence in pipeline mode is a problem.
In pipeline mode the main scan measurements take precedence over all other measurements. Main scan measurements are "grouped" into a single block of measurement opcodes that are executed with precise timing at the start of the scan interval.
Slow Sequence measurements are "sliced" in after all main scan measurements are finished. If there is sufficient time before the next main scan, all measurements for a specific Slow scan will be made together. If there is not enough time, only a few measurements from the slow scan will be sliced in and the others will be after the next main scan.
In the case of the AM25T in slow sequences, the first "slice" of an AM25T instruction advances the mux to the appropriate start channel, then makes the measurement. Subsequent reps advance the mux, assuming it was in the correct state prior to being sliced in.
To correct this problem for your program, rather than using reps in the AM25T in the slow sequence, break the instruction up into individual AM25T instructions with a single rep each. I realize, this is not as clean in the code, but should get around this issue of using the same hardware across multiple sequences.
The semaphore solution you attempted does not work in pipeline mode, because the measurements are not controlled by a task but are rather executed entirely from within interrupts. Semaphores are processing instructions.


MatthewBoyd Feb 5, 2015 05:32 PM

Ahh, I see now. Thank you!


MatthewBoyd Feb 17, 2015 11:35 PM

I tested breaking out the reps into individual instructions, but that still did not help. Below is the code I used, and the values I got (they should be around 5 °C). It all works fine if I move everything from the SlowSequence to the main scan (although I cannot do that for this application).

AM25TRefTemp_C = 24.51
TC_C(1) = 11.94
TC_C(2) = -138.4
TC_C(3) = -INF
TC_C(4) = -INF
TC_C(5) = -INF
TC_C(6) = -INF
TC_C(7) = 18.27
TC_C(8) = NAN

'CR1000.Std.27

PipeLineMode


Const FullPyrSetl_us = 3000
Const AnalogSetl_us = 3000
Dim AM25TIsInRev = True
Dim FullAM25TInteg = _60Hz


BeginProg

Scan(1,sec,5,0)

AM25T(AM25TRefTemp_C,0,mV2_,1,AM25TDiffCh,TypeT,AM25TRefTemp_C,MUXClkPort, _
AM25TResetPort,AM25TExCh,AM25TIsInRev,AnalogSetl_us,FullAM25TInteg,1,0)

CallTable(RTDAndTCTable)

NextScan


SlowSequence
Scan(10,sec,0,0)

AM25T(TC_C(1),1,mV2_5,12,AM25TDiffCh,TypeT,AM25TRefTemp_C,MUXClkPort, _
AM25TResetPort,AM25TExCh,AM25TIsInRev,AnalogSetl_us,FullAM25TInteg, _
TCMultipliers(1),TCOffsets(1))

AM25T(TC_C(2),1,mV2_5,13,AM25TDiffCh,TypeT,AM25TRefTemp_C,MUXClkPort, _
AM25TResetPort,AM25TExCh,AM25TIsInRev,AnalogSetl_us,FullAM25TInteg, _
TCMultipliers(2),TCOffsets(2))

AM25T(TC_C(3),1,mV2_5,14,AM25TDiffCh,TypeT,AM25TRefTemp_C,MUXClkPort, _
AM25TResetPort,AM25TExCh,AM25TIsInRev,AnalogSetl_us,FullAM25TInteg, _
TCMultipliers(3),TCOffsets(3))

AM25T(TC_C(4),1,mV2_5,15,AM25TDiffCh,TypeT,AM25TRefTemp_C,MUXClkPort, _
AM25TResetPort,AM25TExCh,AM25TIsInRev,AnalogSetl_us,FullAM25TInteg, _
TCMultipliers(4),TCOffsets(4))

AM25T(TC_C(5),1,mV2_5,16,AM25TDiffCh,TypeT,AM25TRefTemp_C,MUXClkPort, _
AM25TResetPort,AM25TExCh,AM25TIsInRev,AnalogSetl_us,FullAM25TInteg, _
TCMultipliers(5),TCOffsets(5))

AM25T(TC_C(6),1,mV2_5,17,AM25TDiffCh,TypeT,AM25TRefTemp_C,MUXClkPort, _
AM25TResetPort,AM25TExCh,AM25TIsInRev,AnalogSetl_us,FullAM25TInteg, _
TCMultipliers(6),TCOffsets(6))

AM25T(TC_C(7),1,mV2_5,18,AM25TDiffCh,TypeT,AM25TRefTemp_C,MUXClkPort, _
AM25TResetPort,AM25TExCh,AM25TIsInRev,AnalogSetl_us,FullAM25TInteg, _
TCMultipliers(7),TCOffsets(7))

AM25T(TC_C(8),1,mV2_5,19,AM25TDiffCh,TypeT,AM25TRefTemp_C,MUXClkPort, _
AM25TResetPort,AM25TExCh,AM25TIsInRev,AnalogSetl_us,FullAM25TInteg, _
TCMultipliers(8),TCOffsets(8))

NextScan
EndSequence

EndProg

* Last updated by: MatthewBoyd on 2/17/2015 @ 4:36 PM *


DAM Feb 18, 2015 11:30 PM

Is running in sequential mode an option?


MatthewBoyd Feb 19, 2015 03:04 PM

No, unfortunately there's not enough measurement/processing time.


DAM Feb 19, 2015 03:35 PM

I will look into possible Operating System changes to accomplish what you need.


Anton Jul 6, 2015 08:21 PM

I have successfully run quite similar code a few years ago, but am running into problems this time around. So naturally I am curious what Operating Changes were contemplated or made...

The difference with my previous program is that this time both my main scan and slow scan are much busier (more measurement time).

I put public counters in each of the scans to see what was going on, and it turned out the slow scan was never actually run. Only when I reduced the number of AM25T calls in the slow scan from 16 to about 6, the slow scan would run.

Is this expected behaviour?

Log in or register to post/reply in the forum.