Enhanced Machine Controller

AXIS uses Tkinter, which is a Python wrapper around Tk.

You can directly call tcl commands in axis by using the method
root_window.tk.call().  For example,
    root_window.tk.call("wm", "title", ".", "I changed the window title")
Most Tk commands are also present as methods on widget objects, so
    root_window.wm_title("I changed the window title")
would have the same effect.

If you've written your vw meter in tcl, then the first step is to cause it =
to
be installed alongside the other tcl files in Axis.  Just put the file in t=
he
"tcl" subdirectory with the .tcl extension, and "python setup.py install".

Then, "source" the code in Axis' tcl interpreter.  Something like this:
        nf.source_lib_tcl(root_window, "vw.tcl")
just below the other calls to nf.source_lib_tcl().

Now, add whatever other calls to tcl commands you need to create the
widget and update it.  You can find widget paths by referring to the=20
file tcl/axis.nf, which is just tcl source.

The method 'update' of the 'class LivePlotter' is called periodically,
and would be an appropriate place to change the value on the meter.

Good luck.

Jeff

Hi jeff

          Thank very much for your response, Last night I try to add my tcl 
code into AXIS. May be luck on me....

_________________________________________________________________
On the road to retirement? Check out MSN Life Events for advice on how to 
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement

Any thoughts?

dmesg shows:

PWMCycle = 200
ppmc_PWM V1.0 estop is now 3
ppmc_PWM V1.0 estop is now 4
ppmc_PWM V1.0 estop is now 5
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process sh
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process kdeinit
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
VM: killing process emcsh
going into E-stop
emcmot: cleanup started.
emcmot: deleting emcmotTask.
emcmot: disabling amps
emcmot: quitting analog, digital and motor interfaces
ppmc_PWM V1.1 found a Universal PWM ver 1 module at IEEE-1284 address 0x f
emcmot: releasing rtai shared memory.
emcmot: debounce counts: 0 0 0 0 0 0 0 0
emcmot: cleanup finished.
==== RT memory manager max allocated: 8192 bytes.
==== RT memory manager kernel kmalloc()'s:   4
==== RT memory manager kernel kfree()'s:     4
==== RT memory manager overhead:      0 bytes.
==== RT memory manager leaks:         0 bytes.


==== RT memory manager v1.3 Unloaded. ====


***** THE UP REAL TIME SCHEDULER HAS BEEN REMOVED *****

Adeos: Domain RTAI unregistered.
RTAI/Adeos unmounted.
Adeos: Pipelining stopped.

So, what's going on.

I'm using Jon Elson's release from 8/5/2005.

Ken

Kenneth.Lerman@...
Systems Essentials Limited           Fax: (203)426-9138
55 Main Street                     Voice: (203)426-4430
Newtown, CT 06470             http://se-ltd.com/~lerman
PGP =  B1 66 29 FB CB 8C 6A 24  E1 DF B4 63 2C D6 5D AD

Kenneth Lerman wrote:

>Any thoughts?
>
>dmesg shows:
>
>PWMCycle = 200
>ppmc_PWM V1.0 estop is now 3
>ppmc_PWM V1.0 estop is now 4
>ppmc_PWM V1.0 estop is now 5
>__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
>VM: killing process sh
>__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
>VM: killing process kdeinit
>__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
>VM: killing process emcsh
>going into E-stop
>emcmot: cleanup started.
>emcmot: deleting emcmotTask.
>emcmot: disabling amps
>emcmot: quitting analog, digital and motor interfaces
>ppmc_PWM V1.1 found a Universal PWM ver 1 module at IEEE-1284 address 0x f
>emcmot: releasing rtai shared memory.
>emcmot: debounce counts: 0 0 0 0 0 0 0 0
>emcmot: cleanup finished.
>==== RT memory manager max allocated: 8192 bytes.
>==== RT memory manager kernel kmalloc()'s:   4
>==== RT memory manager kernel kfree()'s:     4
>==== RT memory manager overhead:      0 bytes.
>==== RT memory manager leaks:         0 bytes.
>
>
>==== RT memory manager v1.3 Unloaded. ====
>
>
>***** THE UP REAL TIME SCHEDULER HAS BEEN REMOVED *****
>
>Adeos: Domain RTAI unregistered.
>RTAI/Adeos unmounted.
>Adeos: Pipelining stopped.
>
>So, what's going on.
>
>I'm using Jon Elson's release from 8/5/2005.
>  
>
This is the line that is most likely indicating the problem, but I don't
have the foggiest idea what it is trying to say.  Does this happen right 
when
you get out of estop?

__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)

I am guessing it is trying to allocate some pages of memory, and there isn't
enough free memory available.  I don't know if this has any bearing on 
the problem,
but how much memory do you have on this system?  Did you add any new
software recently?  Did you change anything else on the system?  Did you
have a lot of other programs running at the same time?

Jon

On Thursday 29 September 2005 03:05, Kenneth Lerman wrote:
> __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
> VM: killing process sh
> __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
> VM: killing process kdeinit
> __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
> VM: killing process emcsh

A quick google turns up 17,700 hits on the subject. This is a result of 
running out of memory and the kernel is killing tasks so that the system can 
remain "live". Two short term solutions, check swap usage with "swapon -s", 
enabling with "swapon -a" if it isn't being used. Or whack a load more memory 
in.
Long term, find out what process is using the memory up - It may be something 
has a memory leak and needs upgrading. Installing a newer kernel may help as 
it would appear the OOM killer has had some major reworking during the 
2.4.2xx cycle.


Regards, Paul.

It happens when the system is idle.  I believe it is out of estop but servos
off.  I've never been at the system when it happened.  I have 256 meg of
RAM.

The only change I've made to the system is that I've enabled automatic
standby of the monitor after an hour.

(I guess I'll try turning that off and see if it happens again.)

Ken

Kenneth.Lerman@...
Systems Essentials Limited           Fax: (203)426-9138
55 Main Street                     Voice: (203)426-4430
Newtown, CT 06470             http://se-ltd.com/~lerman
PGP =  B1 66 29 FB CB 8C 6A 24  E1 DF B4 63 2C D6 5D AD

-----Original Message-----
From: emc-developers-admin@...
[mailto:emc-developers-admin@... Behalf Of Jon
Elson
Sent: Thursday, September 29, 2005 12:53 AM
To: emc-developers@...
Subject: Re: [Emc-developers] EMC Exits Unexpectedly


Kenneth Lerman wrote:

>Any thoughts?
>
>dmesg shows:
>
>PWMCycle = 200
>ppmc_PWM V1.0 estop is now 3
>ppmc_PWM V1.0 estop is now 4
>ppmc_PWM V1.0 estop is now 5
>__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
>VM: killing process sh
>__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
>VM: killing process kdeinit
>__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
>VM: killing process emcsh
>going into E-stop
>emcmot: cleanup started.
>emcmot: deleting emcmotTask.
>emcmot: disabling amps
>emcmot: quitting analog, digital and motor interfaces
>ppmc_PWM V1.1 found a Universal PWM ver 1 module at IEEE-1284 address 0x f
>emcmot: releasing rtai shared memory.
>emcmot: debounce counts: 0 0 0 0 0 0 0 0
>emcmot: cleanup finished.
>==== RT memory manager max allocated: 8192 bytes.
>==== RT memory manager kernel kmalloc()'s:   4
>==== RT memory manager kernel kfree()'s:     4
>==== RT memory manager overhead:      0 bytes.
>==== RT memory manager leaks:         0 bytes.
>
>
>==== RT memory manager v1.3 Unloaded. ====
>
>
>***** THE UP REAL TIME SCHEDULER HAS BEEN REMOVED *****
>
>Adeos: Domain RTAI unregistered.
>RTAI/Adeos unmounted.
>Adeos: Pipelining stopped.
>
>So, what's going on.
>
>I'm using Jon Elson's release from 8/5/2005.
>
>
This is the line that is most likely indicating the problem, but I don't
have the foggiest idea what it is trying to say.  Does this happen right
when
you get out of estop?

__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)

I am guessing it is trying to allocate some pages of memory, and there isn't
enough free memory available.  I don't know if this has any bearing on
the problem,
but how much memory do you have on this system?  Did you add any new
software recently?  Did you change anything else on the system?  Did you
have a lot of other programs running at the same time?

Jon



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Emc-developers mailing list
Emc-developers@...
https://lists.sourceforge.net/lists/listinfo/emc-developers

Igor:

This should get you started.

Dave

<http://home.att.net/~jmkasunich/EMC_Docs/EMC_Home.htm>


On Sep 28, 2005, at 8:41 AM, Igor Besic wrote:

> I need help with filling in the diagram of interconnections in EMC. I
> do not quite understand which process is giving instructions to which.
> Thanks!
> --
> Regards,
> Igor Be=C5=A1i=C4=87
>
> <EMCDIAG1.PDF>
>

Hi Jeff

On Saturday 17 September 2005 15:15, jepler@... wrote:
> Here's what apt-get is offering to upgrade for me:
> =A0=A0=A0=A0=A0=A0=A0=A0root@...:~# apt-get update
> =A0=A0=A0=A0=A0=A0=A0=A0Hit http://webersys.com ./ Packages

Comment out the webersys entry or you will get synergy-cad updating every=20
time. I suspect there is something wrong with timestamps on that package.

> [...]
> =A0=A0=A0=A0=A0=A0=A0=A0Setting up bdi-branding (1.2-22) ...
> =A0=A0=A0=A0=A0=A0=A0=A0Setting up emc (1.0-29) ...

Add to the list python2.3-axis (1.0+cvs.20050916) - Just added it to the=20
repository.

To get the latest kernel modules, you'll need to execute:

  apt-get install --reinstall emc-modules-2.6.10-adeos


Haven't had time to look at why the modules are not picked up automatically=
=20
during an update.. Let me know if these latest builds fix the problem befor=
e=20
moving on to the 2.6.12 kernel.


Regards, Paul.

On Sat, Sep 17, 2005 at 03:40:03PM +0100, paul_c wrote:
> To get the latest kernel modules, you'll need to execute:
>=20
>   apt-get install --reinstall emc-modules-2.6.10-adeos

I did this, and it seems to have fixed the problem.
	Setting up emc-modules-2.6.10-adeos (+bdi.92) ...

axis, glxgears, and my test program all behave as expected on the test
system.

Jeff

jepler@... wrote:

>On Sat, Sep 17, 2005 at 03:40:03PM +0100, paul_c wrote:
>  
>
>>To get the latest kernel modules, you'll need to execute:
>>
>>  apt-get install --reinstall emc-modules-2.6.10-adeos
>>    
>>
>
>I did this, and it seems to have fixed the problem.
>	Setting up emc-modules-2.6.10-adeos (+bdi.92) ...
>
>axis, glxgears, and my test program all behave as expected on the test
>system.
>
>Jeff
>  
>
Once again, for what it's worth.

I updated just the emc-modules-2.6.10-adeos package on my BDI 4.27 
system and it fixed the problem. It even ran a piece of gcode that had 
never run to completion, it would always stall out just prior to a peck 
cycle. It's happy now!

Thanks

Oscar

On Saturday 17 September 2005 16:48, jepler@... wrote:
> I did this, and it seems to have fixed the problem.
> =A0=A0=A0=A0=A0=A0=A0=A0Setting up emc-modules-2.6.10-adeos (+bdi.92) ...
>
> axis, glxgears, and my test program all behave as expected on the test
> system.

Looks like I'll be building a BDI-4.29 tonight then - I see axis has had a=
=20
small change, and several KDE packages have been updated over the last few=
=20
days. Along with a 2.6.12 kernel, there should be plenty of changes to make=
=20
it worth while.

Regards, Paul.

On Saturday 17 September 2005 17:52, Oscar Dalem wrote:
> Once again, for what it's worth.
>
> I updated just the emc-modules-2.6.10-adeos package on my BDI 4.27
> system and it fixed the problem. It even ran a piece of gcode that had
> never run to completion, it would always stall out just prior to a peck
> cycle.


Well... It looks like the interim fix results in AXIS_0 ini parameters getting 
trashed - Probably breaks Jon's ppmc drivers as well.
 Need to work on an alternative fix over the next couple of days.


Regards, Paul.

paul_c wrote:

>On Saturday 17 September 2005 17:52, Oscar Dalem wrote:
>  
>
>>Once again, for what it's worth.
>>
>>I updated just the emc-modules-2.6.10-adeos package on my BDI 4.27
>>system and it fixed the problem. It even ran a piece of gcode that had
>>never run to completion, it would always stall out just prior to a peck
>>cycle.
>>    
>>
>
>
>Well... It looks like the interim fix results in AXIS_0 ini parameters getting 
>trashed - Probably breaks Jon's ppmc drivers as well.
> Need to work on an alternative fix over the next couple of days.
>  
>
ARRGH!  Is this because these programs expect static float variables to
remain undisturbed between calls?

I'm guessing the problem before was that the float stack was not being 
preserved by
the RT scheduler.  (Isn't there some flag you need to set so the RT 
scheduler knows
that a particular RT module is going to be using the float stack, so it 
performs the
save/restore?  I remember some issues with this back in 1997 or so.)

Is the PPMC the only driver that uses floating point?  Can't be, I'm 
sure the
STG uses VERY similar code (that's where we got most of it from in the first
place!)

Jon

On Saturday 17 September 2005 20:46, paul_c wrote:
> Well... It looks like the interim fix results in AXIS_0 ini parameters
> getting trashed - Probably breaks Jon's ppmc drivers as well.
> =A0Need to work on an alternative fix over the next couple of days.


OK.. emc-modules for both 2.6.10 and 2.6.12 kernels now available. A perman=
ent=20
fix has been applied that will not break any other driver or screw up user=
=20
space. Anyone wanting to upgrade the emc-modules-2.6.10-adeos package may=20
need to use the --reinstall option with apt-get.


Regards, Paul.

Kenneth Lerman wrote:

>
>The day before yesterday, I did that, but accidently unplugged my milling
>machine instead of the lathe.  I later realized my mistake, so I plugged the
>milling machine back in.
>
>Yesterday, I went to use the mill.  It had some sort of axis errors, but I
>sometimes forget how I left the machine, so I just cleared the errors, took
>it out of estop, and went to rapid the axis to zero, zero.
>
>Whoops, the machine zoomed off the Y-axis scale into the hard stop.  (A
>limit switch an inch from the end of travel didn't help.)
>  
>
OK, I played around with this for a while, and demonstrated the behavior.
I SURE don't understand it, and it is more complicated than I thought.

I was able to power down the UPC controller board about 5 times without
any problems other than going to estop-reset and an axis limit error.  I 
could
then power it back up, get out of estop and make it move in a controlled
manner.  I did lose axis alignment when doing this, of course, so it is not
too good that this can happen without a specific indication that the home
alignment has been knocked off.

But, the 6th time I did it, I got a behavior that has been described to 
me, but
I have not seen before, myself.  When I powered the board back on, the
X axis display started counting up at a fairly high rate, when the system
was in estop or estop-reset.  When in machine-on, the motor would spin,
and the actual position display would remain stable.  The system did not
respond to movement of the encoder.  After this event, the only way to
get it working again was to shut down and restart EMC.  I tried to
reset the condition by cycling power on the UPC board, but it didn't
help.

I don't know where the rapidly incrementing position is coming from, but
I DON'T believe it is coming from the UPC board!  (I will check that
with the logic analyzer.)  The incrementing appears to be .0001" per servo
cycle, or 0.1" per second.  Since the INPUT_SCALE on my test system is
128000 counts/inch = user unit, it would be incrementing 12.8 encoder
counts/servo cycle, which doesn't ring a bell.

I'm wondering if this is somehow related to the encoder reading error
supression logic that was put in to suppress occasional wildly wrong
encoder readings on the STG card?  (If the encoder is moved to some
position substantially far from the original start-up zero position, and
then the UPC or USC board were turned off and back on, the encoder
count would appear to EMC to be reset abruptly to zero, which would look
like an impossible encoder movement.  This would trigger the invalid
count supression logic, which would never recover unless you happened to
move the encoder back close to the original reading.)

Any thoughts on this?  I'm just sort of thinking out loud, trying to
understand this strange behavior.  Obviously, you shouldn't power
off the encoder counters while EMC is running, but we need a way to
detect that and handle it in a robust manner.  (Obviously, a message
like "PWM Controller communication failure - restart EMC" is
probably the right thing to do, but I'd like to understand where this
counting up of the position is coming from.)

Thanks,

Jon

Jon

On Sunday 18 September 2005 05:51, Jon Elson wrote:
> But, the 6th time I did it, I got a behavior that has been described to
> me, but
> I have not seen before, myself. =A0When I powered the board back on, the
> X axis display started counting up at a fairly high rate, when the system
> was in estop or estop-reset. =A0When in machine-on, the motor would spin,
> and the actual position display would remain stable. =A0The system did not
> respond to movement of the encoder. =A0After this event, the only way to
> get it working again was to shut down and restart EMC. =A0I tried to
> reset the condition by cycling power on the UPC board, but it didn't
> help.


I have seen this kind of behaviour under two conditions, the first is one t=
hat=20
will not affect you, the second probably will.

1) The servo loop gets a null pointer and RTAI suspends the task - Only=20
appears to happen safely with 2.6 kernels. The leaves the stepper pulse rat=
e=20
generation task running with whatever data was last passed to it. The ppm=20
driver does not implement the stepper task in software, so this won't happe=
n.

2) Under certain conditions, the PID calculations receive dubious input - T=
his=20
sounds like the sort of response you are seeing. I thought this had been=20
fixed with a simple check on input values..


Let me repeat just in case you missed it first time - Scenario 1 will NOT=20
happen - If the servo loop stops, worst case will require a system reboot.
Checking /proc/rtai will show which tasks are active.

If you are running BDI-4 builds, /proc/emc also has a little window on the=
=20
realtime status of the servo loop.



Regards, Paul.

Hi Ray

On Saturday 17 September 2005 14:49, Ray Henry wrote:
> =A0I suspect that it would be much quicker with the IceWM available with =
the
> latest BDI releases than it is with KDE

Icewm has a whole bunch of gtk-1.2 dependencies that I'd rather not use=20
valuable disk space satisfying. Instead, xfce4 is the lightweight window=20
manager. Two things to bear in mind - There are no native xfce4 icons for=20
EMC, I have not had time to put any together. Second. If space is required=
=20
for other "must have" apps, xfce4 will be the first to be dropped, freeing =
up=20
some 11Megs of disk space.


Regards, Paul.