Problem using AXIS together with HALUI

Hi,

I've found a problem in using AXIS together with HALUI, but it seems a general problem when two or more user interfaces are used the same time.

I use HALUI to start the NC programm by an external trigger (via pin halui.program.run) and found that axis is blocked some times when this function is used. Even more problematic for me is the fact that in some cases the trigger impulse get lost. After investigating the involved code I think I've found the reason. I'll try to describe my thoughts:

The communication between UI and EMCTASK is done by shared mem buffers (cmd + status). If a command is issued, the command object is copied to the cmd buffer (including a command serial number). Then the sender (the UI) waits for the reception and optionaly for the completion of the command. The wait is relized by waiting for the appearance of the issued serial number in echo_serial_number of the status buffer. The serial number generator is local to the ui process and no sync methods (except from a semaphore on the buffer read/write functions) is involved. This causes two problems:

• the first issued command (by AXIS for example) can get overwritten by the second one (e.g. HALUI) before EMCTASK has processed it
• even if both commands are processed correctly, one of the wait functions will time out because the serial number does not match.

My suggestions to solve this probem are:

• using a pipe for the command channel instead of a buffer (RCS_CMD_CHANNEL, I have to check if toolCmd is also affected)
• using the NML method get_msg_count() before write() (with mutex) as serial number generator instead of incrementing a process local variable
• the wait functions sould check if the serial number is greater than the issued one. Then the command is already processed.

If this is a valid concept or someone has a better idea I like to do the code changes. But I need some help on the underlaying cms stuff (How to configure it as a pipe for example)

Regards
Sascha

Hi

Yes there is a problem, where two processes are accessing data and changing states, that they get out of sync.

I think halui was originally envisaged as a way to either provide basic GUI functionality without a GUI, or to provide the framework for a basic GUI at a higher level.
Not to run in parallel with another GUI.

The whole way that commands are processed and NML in its entirety is under review and liable to be changed.
If you subscribe to the emc-developers list you can put your ideas directly to the developers who are looking at it and they will advise how they see things progressing.
(Have a read through the archives first to see what has been proposed to date)

If all you want to do is load a program, one way that will ensure it is not blocking or blocked by other accesses, would be to use a system call to axis-remote.
You could do this directly if writing a component, or through a halui.mdi-command which calls a user M Code bash script or similar

regards

Thank you for your reply and sorry for my late response.
As a needed a quick solution I've decided to create a patch. As it might be interesting for others I've published it here .

Regards
Sascha

That's a huge piece of work, 4000 line patch.

Michael H has put a detailed response on the tracker entry, looks like he thinks you are part way towards a solution of a lot of the current problems with NML buffers.

well done