Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Problem reading global data structures in PLC
I am relatively new to Delta Tau controllers and am having a problem with some PLC code that is reading some values from some global data structures.

The environment I am using:
- Windows 10 Enterprise, vers 1803
- PowerPMAC IDE vers
- Power Brick LV-IMS (PBL8JD01005E00000BNL)
Kernel: 3.2.21-powerpmac-smp
Firmware Vers: (Apr 23, 2018)

A sample of my test code attached.

The problem is with these lines:

// Check the state of the limit bits
call DoNothing(); // negLimit always 0 or 1 without this
negLimit = Gate3[gateIdx].Chan[chIdx].MinusLimit;
posLimit = Gate3[gateIdx].Chan[chIdx].PlusLimit;

As long as I have a function call before reading the Gate3[].Chan[].XxxLimit values, then both statements work. But if I leave out the function call, then only the 2nd one works. If I leave out the function call and repeat either of these statements before the existing 2, then the 1st (redundant) one still fails, but the 2nd and 3rd work.

It seems unlikely, but after much experimentation, the only explanation I can come up with to explain this is that the script code gets compiled and so highly optimized that the 1st read gets moved to before the while loop and so the result is always what it was before the loop actually started. Placing a function call just before this would invalidate the contents of most of the registers, which would force the compiler to do the read where expected within the while loop. This theory would also seem to be supported by the fact that removing the following lines (and leaving the function call out) also results in both the reads working each time:

// If we don't know the PhasePos of the motor, initiate a phase-ref search
if ((Motor[mtrNum].PhaseFound == 0) && (Motor[mtrNum].PhaseFindingStep == 0))
if ((Sys.Time - StartupTime) > 30.0) {
send 0, "%10.2f: phase-ref search\n \n", Sys.Time; //test
Motor[mtrNum].PhaseFindingStep = 1; call Timer(0.01);

The level of optimization required (and # of general purpose registers) for this theory to be true still makes me think there must be another explanation, but so far I have not been able to think of one.

Also, given the statements made in the PLC training video about the while loops determining when a PLC is preempted (or gives up the CPU) makes me think there must be some logic that invalidates the contents of most the registers when this occurs (otherwise this would be a very widespread concurrency problem).

So what am I missing? Has anyone else come across this kind of problem before?

I am very concerned about the fact that there is no simple way to determine where in the code this could be an issue. I cannot believe that everyone has to sprinkle function calls throughout their code (at least in the the PLC code) in order to avoid such things.

Attached Files
.txt   sampleCode.plc.txt (Size: 1.26 KB / Downloads: 19)
We have not been able to duplicate this here, and don't see any internal reason why this should occur.
(12-21-2018, 05:52 PM)curtwilson Wrote: We have not been able to duplicate this here, and don't see any internal reason why this should occur.

Does the PLC code (and presumably the code for motion programs) get compiled in to machine code? Perhaps converted to C code so that it can be compiled by a standard C compiler? And if so, is the compilation done in the IDE or on the controller?
No the Script code (PLC and motion) is interpreted.

Forum Jump:

Users browsing this thread: 1 Guest(s)