[Emc-developers] Task Cycle Time Jitter
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
Re: [Emc-developers] pid bug
--- if ( ( tmp1 * pid-limit_state ) = 0.0 ) {
+++ if ( ( tmp1 * pid-limit_state * pid-igain ) = 0.0 ) {
Is a possible patch if negative PID values are to be allowed
Peter Wallace
Mesa Electronics
--
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
Re: [Emc-developers] Task Cycle Time Jitter
Hello,
I guess I answered my own question with a little more digging:
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) {
...
Indeed, acording to these:
http://export.writer.zoho.com/public/rreginelli/Chapter-5---High-Resolution-Timers-Final1/fullpage
http://readlist.com/lists/vger.kernel.org/linux-kernel/34/171174.html
a call to select() uses low resolution timers, therefore is not
guaranteed to sleep the amount of time desired.
So, the question is: can esleep() be modified to use a high resolution
timer (nanosleep() or similar) or maybe the RCS_TIMER class use this
other method of sleeping (since apparentely it's used only for timing
the main emc task?
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
Re: [Emc-developers] Task Cycle Time Jitter
On Tue, Feb 08, 2011 at 02:36:49PM -0200, Matheus Degiovani wrote: So, the question is: can esleep() be modified to use a high resolution timer (nanosleep() or similar) or maybe the RCS_TIMER class use this other method of sleeping (since apparentely it's used only for timing the main emc task? I think it's the wrong approach to try to make task respond in real time. It is not a real time process. It runs in userspace and therefore there are no guarantees. I think you need to reexamine your setup and find a way to do everything that needs to be fast in real time. You might investigate whether you can find a way to use motion's adaptive-feed or feed-hold inputs to hold the material in place while punching. These work in real time. If a motion is pending and you deassert them, the machine will start to move at the next servo cycle. -- 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
[Emc-developers] getting LyX updates into the Integrator's Manual
About a month ago, I made some substantial updates to the ppmc driver section of the Integrator's Manual (file: docs/src/drivers/pico_ppmc.lyx) but these changes have not showed up yet in the main version of the manual linked from the Wiki page. Is there something I need to do to push these changes into the right branch of the source tree so it gets built into the public version of the manual? Thanks, Jon -- 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
