emcrsh: server part locks up

Hi!
I try to control Emc2 software via 'emcrsh', because i read about this is recommended way to do some non-trivial tasks like SMT Pick and place machine, and other types of external control.
I'm configure my system in standard way so i able milling well. Then, only i change is add 'loadusr emcrsh' in .hal file.
I not find any working example (command sequence) for emcrsh, so i try to write from scratch.
Here is my terminal log:
...but in places shown as (x), i not receive anything, and all stops until i disconnect telnet, and connect again (and 'hello' again, etc) - then 'set machine on' command, which first time always stop telnet server, second time always work. I reproduce it multiple times, and i reproduce it not only in hand mode, but also in simple C code which work in raw string send/receive mode, like telnet.
Where i am wrong? Probably command order?..
Thanks!

I just found topic which describes exactly same problem:
www.linuxcnc.org/component/option,com_ku...ew/catid,10/id,1633/
But it still not has a solution.

Hi!
Still no luck. I also check jitter and try increase Base_period, but it is not helpful.
Any chances to turn it to work?..
Please give me the direction where to search about fixing Emcrsh. Any success stories about using Emcrsh exist?.. Or, maybe another way to control Emc2 from my software, is exist?
Many thanks!

jpka wrote:

set update auto
SET UPDATE ACK
set machine on (x)

Hi

There has been a bit of discussion on emcrsh both here and on the user list, so I thought that I would try it.

The command sequence you posted does produce the result you specified, ie emcrsh seems to lock up and does not respond until restarted on 2.4.5

However, I did not try your sequence to start with and because update defaults to auto anyway, I just did the sequence below.

It worked perfectly, homed the axes then moved to the given co-ordinates.
I did not do extensive testing, just wanted to home and test axis movement, which were the major control items.

I will dig through the emcrsh code later to see if anything leaps out at me as to why and whether this tallies with the bugfix that Andy highlighted.

For now appears the factor which caused the lock-up was the set update auto command.
Seems to work OK if you don't use it.

regards

Hi

Just a quick update.

The workaround from Eric Johnson that Andy flagged up, is basically to issue a
set set_wait none
after enabling.

I tested this and found that emcrsh no longer hung no matter how many
set update none | auto
set machine on | off
etc. commands were issued.

I had full functionality controlling a pre-loaded Axis gui, with emcrsh launched from a terminal after Axis.

The only issue I found, was that emcrsh does not read the .ini file for default file path even if you specify it.
It defaults to ../../nc_files unless launched with the --path switch.

This was easily overcome by creating a symlink ~/emc2/nc_files which pointed to where my default gcode files actually are.

Hopefully this helps

regards

Hi!
Thanks for your replies, either here on web forum, and at emc-users mailing list.
It looks like this problem now solved.
I try to answer questions i get from mailing list and from here:

Are you entering those commands through a telnet
session, i.e. manually typing them?

I use both cases with same result. (I attach my tiny C program here, please see below)

First thing to do would be to use one of the standard configurations, like
stepper_inch, and only change it by adding "loadusr emcrsh" to the
associated hal file. This can isolate the problem from emcrsh specifically
with something to do with your specific configuration.

Sorry but i currently don't know how to use 'stepper_inch', but yes, only i change in my setup is adding "loadusr emcrsh", but it was not in 'stepper_inch' but in almost clean liveCD installation.

If the problem persists, try removing the update command.

It is not helpful.

Also, why are you doing a "set estop off" after a "set machine on"

Reversed order is not work, i don't know why. (again, it can be easy tested using my program below)

BTW, you can use "set echo off" to eliminate the command echo.

Yes, i try it but my C programming skill too low, so when i switch echo off, *some* commands not send answer at all, and i can't easy handle this. But real programmers maybe can help me with it.

It's weird that the sample config works but switching to emcrsh locks it up. Are you sure adding emcrsh was the only change between the working and broken configs?

Adding "loadusr emcrsh" is really only i change. But Emc software itself, and Axis GUI, never locks up, regardless of this. Only that lock up is "emcrsh" server (daemon) itself, and unlocks when TCP/IP reconnect to it (you may see obsolete commented-up code parts to avoid it, in my C example). When "emcrsh" part locked up, Emc itself works just fine, and i'm able to mill.

What are you doing in your base thread that 100 microseconds is not enough?

I don't know. I write about 'base thread' value only because i found, during blind random tests, that if i increase this value, then i get described effect. Maybe it can be helpful for problem catching.

Here's a config based on emcrsh that i'm trying to use for testing, it works well on my machines and may be a useful starting point for you: <git.linuxcnc.org/gitweb?p=emc2.git;a=tre...a1aadbb0191741d0d5a6>

Thank you, i look on it but currently not find a way to use it, i'm too novice now. I try to use it soon, when i dive into EMC philosophy and software structure.

I don't know if you were the one who raised the Sourceforge bug report, but that has elicited a workaround, at least:
thread.gmane.org/gmane.linux.distributions.emc.devel/4983

No, it is not my bugreport, but it describes exactly same problem. Thanks!

However, I did not try your sequence to start with and because update defaults to auto anyway, I just did the sequence below.
(code...)

I repeat this and get same resuls as before, locking up at (x) places:
*Very important that i now turn on computer and start EMC first time after boot-up, and do nothing (press any buttons etc.) with Axis GUI manually:*
...BUT...
now i press ^], q, then start telnet again, and... viola!
When i write my test program, i run it multiple times, either using 'set update auto', 'none' or not using it at all. Then i notice that *first* time after start Emc, it *always* locks at 'set machine on'. (but command itself is work: machine turns on.) Second time it always pass 'set machine on', but *sometimes* locks on some of subsequental commands like (usually) 'set mode mdi'.

And solution is...

Just a quick update.
The workaround from Eric Johnson that Andy flagged up, is basically to issue a
set set_wait none
after enabling.

After this, i get working setup without lock-ups. I test it using C program i attach here. Sorry for my novice code "style".
Emcrsh is still full of questions, i write it in new topic.

Thank you very much!

to get emcrsh to use a non default ini file:

$ emcrsh -- -ini path_to_ini_file

works for me (emc2.5.0~pre2)
the -- separator is required:


$ emcrsh --help
Usage:
emcrsh [Options]
Options:
--help this help
--port <port number> (default=5007)
--name <server name> (default=EMCNETSVR)
--connectpw <password> (default=EMC)
--enablepw <password> (default=EMCTOO)
--sessions <max sessions> (default=-1) (-1 ==> no limit)
--path <path> (default=../../nc_files/)
emcOptions:
-ini <inifile> (default=emc.ini)

Hi Dewey

I was using 2.4.5 because that is what jpka was using but didn't see any major code changes that would explain.

I loaded the .ini file using the emcrsh -- -ini ~/emc2/configs/sim/axis_mm.ini notation,
and it was taking, because I could query get inifile and emcrsh returned the path I had entered.

However if I entered a set open test.ngc the debug return was can't open ../../test.ngc, so it had reverted to the default
and not read the [DISPLAY] PROGRAM_PREFIX = ~/emc2/ngc/ from the .ini file

I did try not specifying any .ini file and then creating symlinks called emc.ini to the actual .ini file I was using and placing them in various directories to see if emcrsh would pick them up, but it didn't. There was no pre-existing emc.ini anywhere in my .../config directory.

Scanning the code for emcrsh, I saw that whilst it loaded the .ini file, it did not make any calls to inifile.Find(..) etc to search for the PROGRAM_PREFIX tag.
At this point, having found a workable solution that met jpka's needs I did not trace through further as I have no actual need for the facility at present, I was just interested in its operation.

regards