Hello,
Background: I'm trying to build a punch press with a "head clear"
sensor. Whenever the "tip" of the press passes a certain height, a
sensor is triggered and the metal sheet should be moved to the position
of the next punch (before the tip reaches the bottom of the movement -
the punching motor is not stopped between punches).
Punching speed is at most 300 ppm. I have about 100-150 milliseconds of
clear time to move the sheet. Currently, the "head clear" signal is
implemented as a motion.digital-in-XX pin, and I can use a standard
Gcode for a given job:
G91
...
M66 P0 L1 Q999
M64 P0
G0 X1
M65 P0
M66 P0 L1 Q999
M64 P0
G0 X1
M65 P0
...
I'm using the digital output as a debugging aid, and checking through
halscope that movement only happens while that output signal is low.
I have a machine already working like this for over a year, without any
problems, but I'm trying to improve punching speed (identifying all
places where there is a delay).
The critical delay is the EMC task cycle time. When comparing the input
and output signals, there are two situations:
1- [TASK]CYCLE_TIME = -0.001: The times between an M66 and M64 commands
are in the range of 2-25 milliseconds. Average seems to be about 7 ms,
but there's a lot of jitter.
2- [TASK]CYCLE_TIME = 0.001: The range is in 15-20 ms. Much less jitter,
but (in my mind) a very height delay (which should have been 1 millisecond).
When running negative CYCLE_TIME and debug mode, min and max cycle time
is 0.0003 to 0.180 seconds (output after program exit) so, a lot of jitter.
Internally, the task cycle is controlled by an RCS_TIMER. Waiting
(AFAIK) is done by the followin line in libnml/os_intf/_timer.c
(function esleep()):
...
if (select(0, NULL, NULL, NULL, &tval) < 0) {
...
Now, these are all my findings so far. I'm guessing the "select* call
isn't really waiting on the appropriate timeout. I assume the task cycle
thread will have some jitter due to the different types of commands it
executes, however 15ms jitter seems an awfull lot. If I could reduce it
to 5ms (at least on the EMC_TASK_EXEC_WAITING_FOR_IO case) I'd already
be pretty happy.
Any tips on how I can proceed next?
Thanks.
--
Matheus Degiovani
Gigatron Software e Treinamentos Ltda.
(18) 3649-4045
MSN: math...@gigatron.com.br
--
CrĂticas ou Sugestões? Ligue para Ouvidoria Gigatron: (18) 3649-4048
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
