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 one MDI command was in a cue we built ahead of the interpreter. I agree that the task planner would be the proper place to handle message flow as NML is constituted and used now, but at the same time I wonder if the issue isn't forced on NML by poor design of the command stream. I know that if I was the machine operator, I wouldn't want the foreman to have a cycle start button in his office up there on the mezzanine. Ray On Wed, 2007-10-03 at 11:31 +0200, Michel Gouget wrote: > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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 > > ------------------------------------------------------------------------- > 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/ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > ------------------------------------------------------------------------- > 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/ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------- 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/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
