Multiple UI synchro: Big problem!

Hello !

I am still developing my Druids. I have now a working one which sends a
correct program to EMC as a sequence of MDI commands. My problem is to send
these MDI commands while the EMC UI (and more specifically the “mini”) is
running.

I understood that there is an NML library, which allows the UI to send
commands to EMC, and receive responses. This is done by sending a command
with a serial_number, waiting for an acknowledge with the same
serial_number, then waiting again for a DONE, still with the same
serial_number.

The problem comes when the druid sends commands. *sometime* an ACK or A DONE
never comes, and instead I get another serial_number.

I wrote a test program and a makefile available here:
http://www.gouget.org/emc/

I don’t see how I can solve this problem; HELP!!!

Michel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Multiple UI synchro: Big problem!

Thanks, Alex, for the help and the pointers;

>From http://www.isd.mel.nist.gov/projects/rcslib/nml-tutorial.pdf , slide
70:

A graphic user interface (GUI)
has been added. Now, the
command buffer has two writers,
and the status buffer has two
readers. NML ensures mutual
exclusion, as before.
Note that multiple writers need to
coordinate their writing to avoid
overwrites. Multiple readers of
queued NML buffers need to
coordinate their reading, to avoid
stolen messages.

So I have to sync emcsh...

Michel

-----Original Message-----
From: emc-developers-bounces@...
[mailto:emc-developers-bounces@...] On Behalf
Of Michel
Gouget
Sent: lundi 1 octobre 2007 21:22
To: emc-developers@...

Re: Multiple UI synchro: Big problem!

I have now a working solution for running multiple UIs at the same time,
which involves using a semaphore, and modifying emcsh.c.

I found that the NML communication in EMC is rather rustic, with absolutely
no synchronization. It is based on buffers which are transmitted on demand.
When 2 processes ask for the same buffer at the same time, the result is
non-deterministic :(. The UIs sample the status buffer, and act accordingly.
As they need to be responsive, the UIs usually don't even wait for command
completion.
All the interaction between the UIs and emc is done through emcsh.cc. So I
modified it to control the access by using a semaphore. When the druid wants
to access emc, it grabs the semaphore, blocking if necessary.

I tried 2 strategies for the UI (source is in http://www.gouget.org/emc ):
- emcsh2.cc : try to grab the semaphore (non blocking), if it fails, don't
perform the op, but return OK.
- emcsh3.cc: grab the semaphore, blocking if needed.

The emc2.cc strategy works surprisingly well, but I don't like it as it is
not very clean....

The emc3.cc strategy works well, but the UI becomes sluggish when the druid
sends mdi commands.

The latest version of the druid (http://www.gouget.org/druids) manages the
semaphore. In order to use it, replace your emcsh.cc with emcsh3.cc, and
recompile emc.

If we want druids support in EMC, we will need to incorporate emc3.cc, or
something similar, in the EMC code; I don't see any other solution.

Re: Multiple UI synchro: Big problem!

This problem also exists for people who use a GUI and halui.

Jeff

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Multiple UI synchro: Big problem!

I looked at emctaskmain.cc . The communication system is adequate when using
a single ui, but cannot work correctly when using multiples. This seems
deeply rooted because of the NML model.

Have you thought of *clean* ways to handle multiple ui concurrently?

Obviously, the uis must be synced; I did it at the ui level using
semaphores, but the natural place for such a marshalling system is emctask.

It looks like switching from NML to another communication subsystem (maybe
custom...) for the ui<->task communication would not involve too much work:
mainly emcsh.cc and emctaskmain.cc . But I have not found a correct
marshalling model yet.

Any ideas?

Michel

-----Original Message-----
From: emc-developers-bounces@...
[mailto:emc-developers-bounces@...] On Behalf
Of Jeff
Epler
Sent: mardi 2 octobre 2007 23:21
To: EMC developers
Subject: Re: [Emc-developers] Multiple UI synchro: Big problem!

This problem also exists for people who use a GUI and halui.

Jeff

Re: Multiple UI synchro: Big problem!

Hi Michel

I'm struggling a bit with this line of thought.  Perhaps it's old age.
I've tested and used multiple interfaces into a running EMC even before
emcsh was written and tickle was applied.  I often run two along side
each other while testing abilities.  

It is pretty easy to get a GUI to be out of sync with the underlying EMC
if it assumes state rather than polling and displaying state.  This is
the old coffee mug "Sense -> Model -> Act" thing.  Most all of the GUIs,
have violated a bit of this during their early development.  I grant you
that there are some GUIish things like current executing line in auto
mode that are not really state based stuff.  I was lost by the notion
that one GUI might "steal" a status message from the other.  I've got to
be reading that thought way out of intended context.

It would also be fairly easy to automate a pair of NML command channels
so that they would interfere with each other but I can't for the life of
me comprehend why we'd want to do that.  Way long ago we had a shop
floor vs office model floating around in our imaginary factory.  The
notion was that the office decided that the shop floor guy was dragging
his ass so the office guy would press cycle start for him.  I recognize
that this is a pretty primitive notion compared to the GUI/NML processes
you are developing but I'm wondering if the idea is the same.

I also grant that there are issues with successive commands in MDI mode.
I've tried a dozen ways around the fact that the interpreter does not
provide a good way to stack MDI lines and build a proper set of
canonical cards.  We even tried switching from MDI to auto if more than

EMC2 for simultaneous 5-axis manufacturing

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

_______________________________________________
Emc-developers mailing list
Emc-developers@...
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: EMC2 for simultaneous 5-axis manufacturing

On Thu, Oct 04, 2007 at 01:02:55AM +0800, M.H Johnson wrote:
> insmod: error inserting '/usr/realtime-2.6.15-magma/modules/rtai_smi.ko': -1 No such device
> Realtime system did not load

This is likely to be the "real error".  I am not aware of any code in
the 2.1.x or CVS versions of emc that would request this module be
loaded; have you changed your local version to do so?

For an "insmod" error, there is often extra information shown at the end
of the output of the "dmesg" command.

> Machine configuration directory is '/home/cm/Desktop/emc2/20070518/configs/hexapod-sim'

If you are using a copy of emc from May 18, please update it.  Since
that time many bugs have been fixed in both the stable release version
and in the CVS TRUNK version.

> EMC terminated with an error.  You can find more information in the log
> files
>     /root/emc_debug.txt

Never run emc2 as root.  Instead, use "sudo make setuid" to make the
emc_module_helper program able to load modules, and run it as a "regular
user".  For instance, I have been informed that when you run as root,
the special device file "/dev/tty" is removed when emc exits; this
does not happen when you run as a user.

Jeff

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: EMC2 for simultaneous 5-axis manufacturing

M.H Johnson wrote:
> Dear Helpers,
>     Now I'm going to compile EMC2 for the control of simultaneous 5-axis 
> manufacturing, but something puzzles me deeply.
>     I tried to modify some files which correlate with the hexapod-sim, 
> as shown below ("--->" means "has been changed to" ) :
Have you compiled a version of EMC before on this system?  (I am 
guessing the answer is no.)

You may have to add some system components with the apt-get 
facility to have everything you need to do a compile.  There is 
some info in the wiki under "Installing EMC2" and then under
"Preparing other versions of Linux to compile emc2".

Then, you will probably need to do :

make clean
./configure --run-in-place
observe the output for things it says are not present that will 
prevent "something" from being built.  It is a few lines in the 
midst of a LOT of text.

Once you get it so it doesn't complain about any missing 
libraries, etc., then you can do the

make
sudo make setuid

Jon

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: EMC2 for simultaneous 5-axis manufacturing

----- Original Message ----- 
From: M.H Johnson
To: emc-developers@...
Sent: Wednesday, October 03, 2007 8:02 PM
Subject: [Emc-developers] EMC2 for simultaneous 5-axis manufacturing

<snip>
        EMCMOT =              motmod     --->     EMCMOT = 
freqmod.o
</snip>

This won't work. There is no freqmod in emc2, you need to leave that option 
alone.

Best regards,
Alex Joni

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/