Dear All, I finally solved the problem of running *reliably* multiple UIs simultaneously on EMC, and I have now a Surfacing Druid running smoothly and reliably along mini or axis, without slowing the GUIs. As a side effect, I had to dive deeply into EMC, and I begin to understand it a little bit more ;)
The problem was that sometimes the Druid did not received acknowledge of NML commands that it sent. This has 3 reasons: - EMC has absolutely no synchronization between the GUI and emctask; both poll cyclically their communication channels and pick info on the fly. This is OK when the GUI does not care about the ack of a command - fire and forget ;) -, but it makes automating EMC operations nearly impossible. - Emctask polls the buffers a lot faster than the GUIs; so it can get a command from GUI1, and send immediately the result to GUI2. - There is a single space of command serial_numbers, which means that serial_number clashes are a possibility. The net result is that it is impossible actually to run simultaneously multiple UIs on a single EMC when they need to know when a command is executed. The solution: - Add a semaphore for ensuring exclusive access to emctask by multiple Druids. When emctask starts, it creates this semaphore if needed (its semid is based on the .ini file), and set it to 1. When a Druid needs exclusive access, it decrements it, waiting if needed, sends its commands and then release the semaphore, setting it back to 1. - Add message queues (1 per Druid) for sending back to a Druid the result of its commands. This message queue is created by a Druid when it starts, and removed when it exits; its msgid is based on the .ini file, and the processid of the Druid. The messages are the command serial_number, and the command status (RCS_DONE...) - Add a second Command Buffer (druidCommandBuffer) to EMC, which is reserved to Druids, and is polled by emctask alternatively with the regular command buffer. If emctask receives a command in this buffer, it refuses the commands received in the emcCommandBuffer (except ESTOP, for security reasons). - Add an "originator_msqid" member to RCS_CMD_MSG and to EMC_STAT. this member is filled by the Druid with the message queue id on which it waits for the RCS_DONE status of its commands. For legacy GUIs, this member is initialized to -1 by the constructor. This has also the side effect of removing potential serial_number clashes. A patch against EMC 2.1.7 (done with "cvs diff -u8p", applicable via "patch -p0 <emc_druid.patch") is available here: http://www.gouget.org/druids/download/emc_druid.patch And the source of the Druid is available there: http://www.gouget.org/druids/download/dsurf.tar.gz Info about the Surfacing Druid is available there: http://www.gouget.org/druids/ The only real inconvenient is that the Druid must run on the same system as emctask, because of the semaphores and message queues, but this is also the case of halui. The patch does not modify or change the behaviour of existing GUIs, and the load increase is not perceptible. It allows for an arbitrary number of GUIs to run simultaneously on a single EMC. Could someone review this patch for a possible inclusion in the EMC tree? Best regards, Michel ------------------------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
