Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Inconsistent GPIO Output pulse from motion program
#1
Hello,

We are using a motion program to increment motor positions and then send out a trigger pulse from the GPIO at each new position (a step scan, triggering a detector at each step)

Generally this works well, but we have noticed that we occasionally have missing trigger pulses. eg If I run a 5000 point scan I may only see 4996 triggers from the GPIO.

When I monitor the output I see that occasionally a trigger pulse is remaining high for over 2.5 times longer than usual, enough time to cause the next rising edge to be ineffectual. ie - the pulses we are missing are being swallowed up by the previous trigger remaining high for too long.

This appears to happen at random - there is no apparent periodicity to these long pulses and I can get a different number of them per scan (although typically in the order of about 4-10 per 5000 points)

Below is the way we have structured our motion program:

#define TRIGGER_OUTPUT Acc65E[0].DataReg[3].3

open prog 11

WHILE(COUNTER < NUM_STEPS)
{
CALL SENDTRIGGER;
COUNTER = COUNTER + 1;
DWELL 10;
}

RETURN;
CLOSE

OPEN SUBPROG SENDTRIGGER
X(X_MOVE);
DWELL0;
TRIGGER_OUTPUT == 1;
DWELL(DWELL_TIME/2);
TRIGGER_OUTPUT == 0;
DWELL(DWELL_TIME/2);
RETURN;

CLOSE

What could be causing the random long pulses?

Is there a better, more reliable way to trigger GPIO outputs for this type of task?

Thanks for any guidance,

James
Reply
#2
The Position Compare feature would be more reliable for this, although its output comes from a dedicated connector, not from GPIO. See "Hardware Position-Compare Functions" starting on page 789 of the PPMAC User's Manual. It allows for digital outputs to be toggled at the exact programmed encoder count and will not miss any as the comparison is performed in hardware, not software.

You just have to program your on/off positions (CompareA/CompareB) before you move to the "on" position. If you have uneven spacing, you have to set each one up beforehand. A common practice is to precompute all of the on/off positions, load them into Sys.IData[] elements beforehand and load them in to the CompareA/CompareB registers as you reach each position. This can be done in a simple subprogram call or you can use the capture-compare interrupt service routine (ISR) to do this.

If you have even spacing, you can set up auto-increment, and PMAC automatically toggles the output as your motor counts pass through the preset spacing.
Reply
#3
Hello,

I've been working at the motion program approach for some time now but had some success today....

I found that I could get reliable triggering from a PLC (but obviously without any motions) with the following code:

#define DET_TRIGGER_OUTPUT Acc65E[0].DataReg[3].3
#define trig_count p1401
#define TimeDelay 0.005

open plc 14

local delayTimer;

while(trig_count < 5000)
{
delayTimer = Sys.Time + TimeDelay;
DET_TRIGGER_OUTPUT = 1;
while (Sys.Time < delayTimer)
{
}
delayTimer = Sys.Time + TimeDelay;
DET_TRIGGER_OUTPUT = 0;
while (Sys.Time < delayTimer)
{
}
trig_count++;
}
CLOSE;

So this morning I stripped the motion program right down and removed all motion elements so it resembled the PLC code as closely as possible (with the main loop identical to above).

Curiously this setup could never achieve more than 4096 while loop cycles before it locked up. Less than 4096 it would run to completion, but any more and it would hang. 4096 is too much of a magic number to not be linked to some limitation in the system....I would be interested to know if anyone can shed any light on this limitation?

However, even with this stripped down version running less than 4096 loops it still couldn't reliably trigger. I tried various arrangements of the code and subroutines with no luck.

In the end the successful collections came by modifying the motion program so that it didn't send trigger requests to the hardware directly but would just set a p-variable. Then I had a PLC running alongside the motion program and monitoring this p-variable. The PLC would be the one to actually send the request to the GPIO hardware.

It is not a very elegant solution but seems very reliable. Every collection has been successful. I have run 4 successful collections with a 20ms mark/space length (2 of 4000 steps, 2 of 5000 steps), and 2 successful 5000 step scans at 5ms mark/space length.

It seems that motion programs are unreliable at talking to hardware directly, I'm guessing it has something to do with the way they buffer upcoming moves; it must mess up the timing?

Thanks,

James
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)