Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
position compare output
#1
I'm using the position compare for the 4th axis of the ACC24E2A. It works ok, and I see the expected result on the scope. But I would also like to monitor in the PMAC.

is Gate1[4].Chan[3].Equ the correct channel to monitor?

Thanks
Reply
#2
That should be the correct location to monitor the output. Is it not changing?
Reply
#3
Seems not. I know the system is basically working because I can see the output in the scope. In one motor scan there should be 200+ trigger signals sent out from BEQU1. But with my code I only see 3 changes and 2 rising edges.

The pulse width is 0.4ms so it's conceivable that we're missing the triggers but given that I measure 400,000 Hz (0.0025ms) for the program loop, that shouldn't be happening.

Also, my understanding is that Gate1[4].Chan[3].Equ measures the logical output. Is there another variable that measures the actual output?

OPEN PLC TestTrigger
local currentValue
local lastValue
local start_time_sec

start_time_sec = Sys.RunTime

//debug5 = 0
while (Motor[6].DesVelZero == FALSE)
{
﹒﹒currentValue = Gate1[4].Chan[3].Equ
﹒﹒if (currentValue != lastValue)
﹒﹒{
﹒﹒﹒﹒debug6++
﹒﹒﹒﹒debug7 = currentValue
﹒﹒﹒﹒if (currentValue == 1) //only count rising edge
﹒﹒﹒﹒﹒﹒debug5++
﹒﹒﹒﹒lastValue = currentValue
﹒﹒}
}
monitor_frequency_Hz = 1.0/(Sys.RunTime-start_time_sec)

CLOSE
Reply
#4
This code runs far too slow to capture position compare output. PLCs run in the background. That code is running with a frequency of at most one while loop scan per 1 ms. If you want the real frequency, you can compare the time at the end of the routine to the time at the end of the last run. Alternatively you can look at the background frequency in the IDE task manager.

I would try using the plot tool to capture these pulses. Try comparing your phase frequency to the intended frequency of EQU output to see if phase rate data gathering would be fast enough.
Reply
#5
I thought it was more like a PC running a normal priority thread which would be very quick. Are the plc routines compiled to assembly when executed or are they interpreted during execution? I remember reading something about higher priority plc routines in one of the manuals. Would that be useful?

I will measure the time between execution using your suggestion, which would be useful to know. Since all the triggers will be in the same while loop, it seems I should look at the time between loop iterations.

Also, I will try the plot utility. I assume that uses some special mechanism that allows it to run faster.

Thanks
Reply
#6
The PLC's are interpreted.

We treat the while loops in PLCs in a special manner. Script PLCs only run through one iteration of a while loop per background cycle. Then between background cycles PMAC waits based on Sys.BgSleepTime. This means the following PLC will not cause any other PLCs or PMAC functions to lock up.

Code:
OPEN PLC 1
Jog+ 1
WHILE(Motor[1].InPos==0) {}
DISABLE PLC 1
CLOSE
Reply
#7
PPMAC is a little more flexible than the conventional looping practiced in traditional PLC hardware from other suppliers.

A good overview can be seen in two sections of the May 2019 PPMAC Users Manual:

- 'POWER PMAC COMPUTATIONAL FEATURES' [pp 516] opens with a section titled 'Computational Priorities'. This deals with repetitive (looped, sort of) tasks such as motion and plc programs.
Page 65 lists tasks based on the various clock interrupts.

- 'WRITING C FUNCTIONS AND PROGRAMS IN POWER PMAC' [pp 807] deals with executing compiled C code within PMAC. C code executes much faster than interpreted script and can be executed from a hardware capture interrupt. Danger in hogging too much of the available resources if you do too much, too often.

'Data Gathering' is another option for collecting data (no logic execution), but may not trigger often enough for your needs. Max frequency is Phase clock.
See pp 33 in User Manual.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)