Michael, dont get too excited, we do understand you are busy, and this can of worms causes issues, now that you have taken off the lid. As it should, because any oldish project has issues like this. And they do need to get resolved!! there is no doubt about that.
At the same time I personally *highly value* your time and contibution that you freely give to the project. So that out of the way: This is my considered input to the issues I have seen coming past my eye. (And I probably missed some, but never mind) 1. The matter of old Gene feeling ignored: This is at least in part caused by silly SourceForge that has ideas. I also failed to log a bug report when I tried just now Partly my set up, partly Source Forge, partly wrong info on the wiki page. (*Please drop me a note whoever is maintaining this part of the business*) If I myself were pushed in a corner like he is at the moment, I would probably have exploded a bit louder, with your permission. 2. The program vs MDI issue: operators love to quickly do something and not write a big program, so that is why there is MDI. It is a human interface concept, nothing more. But a very important one. In general it is used slowly and not concurrent with a program, except by code-breaking specialists like me and you. But then again we dont stand behind a real machine all that often. >From architectural point of view it is just another file that needs executing, you are right about that. 3. I understand that the present situation is not at all SAFE from a conceptual point of view. But in practice people have not noticed it. It is not worse than taking all safety switches off a machine, as is often done when they get in the way of expediency. (Yes I know that is shocking!) 4. So I would vote to revert to a release before you disabled the faulty code, and publish a formal warning from the directors of the project on the users list. 5. At the same time someone(two, three) might volunteer to be the active maintainer(s) of the specs of the project, and also be the safety officer(s), since we deal with real, powerful and dangerous machines here. If you have ever seen pieces of casting fly though the workshop because of a faulty control you will know what I mean!. And safety laws are definitely not getting any easier. 6. MOST IMPORTANT. Would the board please pay attention to the state of the project. You people did a wonderful job getting all this started and bringing it where it is today, but at the same time life went by, smoothly and without a ripple; we all lived off the glorious past. But now that there is some real and very needed development going on, to get LCNC up to todays standards, the stress cracks start to show. So lets get focussed and not into each others hair! Regards, Jan de Kruyf. On Thu, May 3, 2012 at 9:14 PM, Michael Haberler <[email protected]> wrote: > > Am 03.05.2012 um 17:35 schrieb Chris Radek: > > > On Thu, May 03, 2012 at 01:35:13PM +0200, Michael Haberler wrote: > >> > >> note I proposed handling proper queuing of MDI commands by modifying > >> Axis to have a queue of MDI commands, and feed them to task one by one > >> within the interpreter state constraints. > > > > I have said this before but maybe not plainly enough - > > No I havent heard it, and I didnt find it in the linuxcnc requirements/API > spec document either. Where is google search with useful results when we > need it > > > I think this > > isn't something to fix in AXIS because if we want MDI queueing to work > > (and I hope we do, somehow) it should work for all UIs. > > Considering that this may be a valid argument, under which light it > behooves to specify: > > - the interpreter input handling needs a queue, which will reside in task > for now and have some configurable maximum size > - that queue shall be flushed on any interpreter abort > - task needs a way to report queue state, (size, and full condition) > - emcmodule needs to enabled to report said state to a caller > - task will drive dequeuing and feeding of interp commands from that list > - the UI's shall observe the 'input queue full' status to disable any > input facility > > The above shall be added to the core linuxcnc requirements/API spec, in > other words: fed into the #linuxcnc-dev IRC channel. > > While mhaberler is away, said IRC channel is tasked to deliberate and > decide the following question: > > - does it make any sense to differentiate input handling mechanisms wrt > 'auto mode' and 'MDI mode' AT ALL, OR is it ok to have the interp input > queue carry any command of the types 'open ngc file', 'execute ngc file' > and 'execute a string (aka MDI mode)'? > > mhaberler can think of no valid reason for two interfaces right now, as he > has never understood the conceptual difference between auto mode and MDI > mode in the first place except for 'string' versus 'file', which obviously > at some distant past was meant to mean 'single block' versus 'several > blocks in a file' > > - Michael > > style reference: http://static.mah.priv.at/public/dambeaver.txt and > assorted EU directives > > > > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Emc-developers mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
