Mario. | 1 Mar 2009 08:33
Picon

Re: Andreas intro: Fixed Interrupt Frequency

I have the ultimate goal of reaching 2 milion quadrature output
changes per second from any of the outputs, even 200 thousand per
second is almost good for me.
How does your method help me get to the intended goal? I'm talking
about parallel port of course.

On Sat, Feb 28, 2009 at 10:09 PM, Andreas Strecker <astrasis <at> gmx.de> wrote:
> Dear Developers
> I am new to your Mailing List and want to introduce myself: I live in
> Germany, studied applied Engineering of Mechatronics some years ago and i am
> fascinated of CNC Stepper Software.
> The first SW i used was written in TurboPascal, using DOS, the code came
> along with the SMC1500 from Conrad Electronics.
> I programmed new functions and made my own special Program to build forms
> and cores for Modelist Airplanes Wings. For this, i built a machine together
> with good friend.
> From the beginning, i had the feeling, that there was something wrong with
> the original code and the principles of generating steps. It took me some
> years to find out, that the way of generating 3D-Steps was suboptimal.
> The original SW was calculating steps in a way like Grafics SW. It just
> created a loop with the periodicity of the fastet axis and the other two
> axis were dependent on this. If i tried to optimize the parameters Maximum
> Velocity and Acceleration for only one axis acting alone, i could get very
> good results, reaching the maximum step frequency delivered by the SMC1500.
> But if i tried to mill with these parameters using arbitrary 3D-Vectors, it
> lost steps massively. Even reducing the Maximum Velocity to one fourth never
> worked out perfectly. The effectiveness was bad, it took 8 hours and more to
> build one form.
> But: There was solution. I found out, that taking the fastest axis to create
> the periodicity was the wrong way. I reprogrammed the whole kernel so the
(Continue reading)

Eric H. Johnson | 1 Mar 2009 17:58

Thoughts on a job scheduler

Hi all,

I am thinking about implementing a job scheduler in EMC and soliciting ideas
on how to do it and what features to include. I know within both Linux and
EMC, 'scheduler' can be an ambiguous term. By job scheduler I mean the
ability to schedule a sequence of g-code files to run in a specified order
and at a specified location in the work area.

I have occasions to run lots of small parts the size of labels, jewelry,
etc., so many individual parts can fit in the work area. But I don't want to
combine them into a single large file, because while some are running,
others are being edited in some graphics or CAM package.

My idea is to use the basic interface shared by emcsh, emcrsh, etc. to
monitor the machine state, run state, etc. and if scheduling is enabled,
when it detects that a job has finished, move to the defined starting
location, and then load and run the next job in queue. Enabling the
scheduler would simply require adding something like "loadusr emcsched" into
a hal file. 

The scheduler would basically implement a queue similar to a standard c++
container class with functions like:

Append to queue
Insert at front
Insert at location
Move an entry up
Move an entry down
Retrieve an entry by index number
Delete an entry by index number
(Continue reading)

Michael Buesch | 1 Mar 2009 18:12
Picon
Favicon

Re: EMC2-stable crashes system (reproducible)

On Friday 27 February 2009 21:58:50 Jeff Epler wrote:
> On Fri, Feb 27, 2009 at 09:42:25PM +0100, Michael Buesch wrote:
> > Does emc use stuff like inline assembly or other special stuff
> > inside of the kernel?
> 
> A bit, but not much.  rtapi_bitops.h and rtapi_math_i386.h have inline
> asm, but I think the first just delegates to <asm/bitops.h> in
> kernelspace[1] and the second is only for i386 (shouldn't apply to
> x86_64)[2].  sim_common.h uses it for rdtsc, but that's not used on a
> system with actual realtime.
> 
> Jeff
> [1] #if (defined(__MODULE__) && !defined(SIM))
>     #include <asm/bitops.h>
> [2] #ifdef __i386__
>     #include "rtapi_math_i386.h"

Ok, I'm still on this and I want to get a bugreport to the gcc folks
and probably a workaround into emc2.

But it's pretty hard to find the place where it does actually crash.

The first thing I need to know is where in the code tree is the kernel
code that handles arc moves (G2/G3)?

--

-- 
Greetings, Michael.

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
(Continue reading)

Dave Engvall | 1 Mar 2009 18:21
Favicon

Re: Thoughts on a job scheduler


On Mar 1, 2009, at 8:58 AM, Eric H. Johnson wrote:

> Hi all,
>
> I am thinking about implementing a job scheduler in EMC and  
> soliciting ideas
> on how to do it and what features to include. I know within both  
> Linux and
> EMC, 'scheduler' can be an ambiguous term. By job scheduler I mean the
> ability to schedule a sequence of g-code files to run in a  
> specified order
> and at a specified location in the work area.
>
> I have occasions to run lots of small parts the size of labels,  
> jewelry,
> etc., so many individual parts can fit in the work area. But I  
> don't want to
> combine them into a single large file, because while some are running,
> others are being edited in some graphics or CAM package.
>
> My idea is to use the basic interface shared by emcsh, emcrsh, etc. to
> monitor the machine state, run state, etc. and if scheduling is  
> enabled,
> when it detects that a job has finished, move to the defined starting
> location, and then load and run the next job in queue. Enabling the
> scheduler would simply require adding something like "loadusr  
> emcsched" into
> a hal file.
>
(Continue reading)

Jeff Epler | 1 Mar 2009 19:21
Favicon

Re: EMC2-stable crashes system (reproducible)

On Sun, Mar 01, 2009 at 06:12:54PM +0100, Michael Buesch wrote:
> But it's pretty hard to find the place where it does actually crash.
> 
> The first thing I need to know is where in the code tree is the kernel
> code that handles arc moves (G2/G3)?

I think the kernel side part is src/emc/kinematics/tc.c -- look for pmCircleXxx API calls.

It crosses my mind that lines are unlikely to call sin/cos but circles
are sure to -- maybe you should see if a component like siggen, which
will call sin/cos, exhibits the same problem.  (and if it doesn't, I
must be barking up the wrong tree with that guess)

Jeff

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
Mark | 1 Mar 2009 19:56
Picon
Gravatar

Re: Thoughts on a job scheduler

Long ago there was some discussion of the task planner, what it did, and functionality that should be added to it.  I didn't find the thread I'm looking for, but IIRC something similar to your scheduler was discussed.

I'd say the task planner is the right place to do it.  At least, in FBICS the planner is responsible for choosing which operations happen in what order.  EMC came from the same people.

On the other hand, I have proven to be dangerous around real-time code, so don't pay *too* much attention to me. :)

Mark


On Sun, Mar 1, 2009 at 11:58 AM, Eric H. Johnson <ejohnson-kAsUra/fN7TuufBYgWm87A@public.gmane.org> wrote:
Hi all,

I am thinking about implementing a job scheduler in EMC and soliciting ideas
on how to do it and what features to include. I know within both Linux and
EMC, 'scheduler' can be an ambiguous term. By job scheduler I mean the
ability to schedule a sequence of g-code files to run in a specified order
and at a specified location in the work area.

I have occasions to run lots of small parts the size of labels, jewelry,
etc., so many individual parts can fit in the work area. But I don't want to
combine them into a single large file, because while some are running,
others are being edited in some graphics or CAM package.

My idea is to use the basic interface shared by emcsh, emcrsh, etc. to
monitor the machine state, run state, etc. and if scheduling is enabled,
when it detects that a job has finished, move to the defined starting
location, and then load and run the next job in queue. Enabling the
scheduler would simply require adding something like "loadusr emcsched" into
a hal file.

The scheduler would basically implement a queue similar to a standard c++
container class with functions like:

Append to queue
Insert at front
Insert at location
Move an entry up
Move an entry down
Retrieve an entry by index number
Delete an entry by index number
Empty the queue
Get number of elements in queue

A few additional commands would include:
Enable scheduler
Disable scheduler
Retrieve an entry by Tag Id
Delete an entry by Tag Id

Each queue record would have fields such as (i.e. not necessarily an
exhaustive list):

IndexId   - Ordinal location in queue
TagId     - User defined field to be used as desired by a UI for example.
Program   - Path and name of g-code file
Zone      - G54 - G59.3 selection of coordinate system
X         - Machine coordinate X offset to use if Zone is not specified
Y         - Machine coordinate Y offset to use if Zone is not specified
Z         - Machine coordinate Z offset to use if Zone is not specified
Feed rate - Override value for feed rate
Spindle   - Override value for spindle speed
Tool      - Default tool number for job

The interface could be just a c/c++ style object (.o) or shared object (.so)
file, unless there is some more convenient means for any of the user
interface.

Any suggestions appreciated.

Regards,
Eric



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Emc-developers mailing list
Emc-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Emc-developers mailing list
Emc-developers@...
https://lists.sourceforge.net/lists/listinfo/emc-developers
Jon Elson | 1 Mar 2009 20:00

Re: Andreas intro: Fixed Interrupt Frequency

Mario. wrote:
> I have the ultimate goal of reaching 2 milion quadrature output
> changes per second from any of the outputs, even 200 thousand per
> second is almost good for me.
> How does your method help me get to the intended goal? I'm talking
> about parallel port of course.
>
>   
It will be totally impossible to make a motherboard parallel port output 
2 million changes per second.
Even if you coded up :
loop :    outb 0x378
        not A
        outb 0x378
       jmp loop

you would only get a little over 1 million changes/second.

Even getting 200 KHz output with complex code is very unlikely.  You 
would need to set the interrupt frequency to 200 KHz = 50 us, and then 
there would be a huge step from 200 KHz down to 100 KHz.  It would not 
be possible to have any frequency between 100 KHz and 200 KHz.
You could set the interrupt frequency to 400 KHz or 25 us, but that is 
near the limit.  It only slightly improves the problem.

I make a board with step rate generators built into an FPGA.  Each 
generator has a 24-bit counter running at 10 MHz.  The computer 
calculates what the count should be to output a pulse.  So, to get 
123.456 KHz, you divide 10 million by 123456 and get 81 counts.  So, you 
program 81 into the counter's limit, and you get your step pulses at the 
desired rate.  (Actually, the counter would count up from (2 ^ 24-1) - 
81, and when it overflows, that generates the step pulse.)

This allows very fine frequency resolution at high step rates, far 
beyond what you can do with software.  Since the steps are generated 
autonomously from the CPU, the board counts the steps going out, and the 
CPU can read the current position.

There are a few other boards that work in similar ways to do this job.

Jon

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
Jon Elson | 1 Mar 2009 20:03

Re: EMC2-stable crashes system (reproducible)

Michael Buesch wrote:
> On Friday 27 February 2009 21:58:50 Jeff Epler wrote:
>   
>> On Fri, Feb 27, 2009 at 09:42:25PM +0100, Michael Buesch wrote:
>>     
>>> Does emc use stuff like inline assembly or other special stuff
>>> inside of the kernel?
>>>       
The PPMC driver (for Pico Systems boards) uses a bunch of INB and OUTB 
"instructions" to directly access the parallel port.
How those are actually implemented at the machine code level is not so 
clear, they may not actually code to those machine instructions.

Jon

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
John Kasunich | 1 Mar 2009 20:45

Re: Andreas intro: Fixed Interrupt Frequency

Jon Elson wrote:
> Mario. wrote:
>> I have the ultimate goal of reaching 2 milion quadrature output
>> changes per second from any of the outputs, even 200 thousand per
>> second is almost good for me.
>> How does your method help me get to the intended goal? I'm talking
>> about parallel port of course.
>>
>>   
> It will be totally impossible to make a motherboard parallel port output 
> 2 million changes per second.

Agreed.

> 
> Even getting 200 KHz output with complex code is very unlikely.  You 
> would need to set the interrupt frequency to 200 KHz = 50 us, 

200KHz interrupts is a 5uS period, not 50uS.  Not happening on any PC.
I think Alex Joni once got the period down to about 6.5uS, just to see
how far he could go.  The machine was not very usable at that point.

> You could set the interrupt frequency to 400 KHz or 25 us,

400KHz is 2.5uS, not 25uS.  Even more impossible.

Software generation in a PC at those rates is simply impossible.
Hardware is the way to go.

Regards,

John Kasunich

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
John Kasunich | 1 Mar 2009 20:46

Re: Thoughts on a job scheduler

Mark wrote:
> Long ago there was some discussion of the task planner, what it did, and
> functionality that should be added to it.  I didn't find the thread I'm
> looking for, but IIRC something similar to your scheduler was discussed.
> 
> I'd say the task planner is the right place to do it.  At least, in FBICS
> the planner is responsible for choosing which operations happen in what
> order.  EMC came from the same people.
> 
> On the other hand, I have proven to be dangerous around real-time code, so
> don't pay *too* much attention to me. :)
> 

You should be safe - both the task planner and any future job scheduler
are in user-space, not real-time.  ;-)

Regards,

John Kasunich

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H

Gmane