Jump to content
OMRON Forums

Problem reading global data structures in PLC


Recommended Posts

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.


Link to comment
Share on other sites

  • Replies 3
  • Created
  • Last Reply

Top Posters In This Topic

  • 2 weeks later...

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?

Link to comment
Share on other sites

This topic is now closed to further replies.

  • Create New...