Am 26.08.2012 um 10:08 schrieb Chris Morley: > >> From time to time I was thinking on Stuart's talk about error/debugging >> messages. > While working on Gscreen I added a message system. > > It uses HAL pins to trigger a dialog/ desktop notification/ sound. > I think this would work fine for user created components and ladder programs. > It would be a lot of INI/HAL code to set up many error cases. > > What it doesn't work well with is default components because most (all?) > don't a have > error protocol in place (might just have an error bit pin) > > For instance VDF components have no way to tell the operator that there is a > specific > problem, even if the VDF it's self could tell you. > > So here is an imagined system : > A component that monitors all error messages HAL based. > This component would be separate from the GUI screen. > > On the HAL side this component could monitor the HAL components that have > registered an error bit pin and a error S32 pin. > So now the component knows the HAL component name, has an error flag, > and an error number for look up. > using the HAL components name it looks up a text file for the messages. > > VDF.message > 1 critical "loss of main power" > 2 info "speed increase not possible - VDF at maximum speed" > etc > > so critical errors throw an estop, info does nothing. > > Obviously not all HAL components need an error system so they would not > export error pins and the message component would ignore them. > As a component builder one would be expected to add the pins and logic to > control them in the component and make a message look up file. > If the message component was smart enough you wouldn't need to connect > these error pins - it could search for them, though this might have > limitations. > > if it notices an error it looks up the message and then either display the > message > it's self or sends it as an NML message so the gui screen can deal with it. > > Thoughts?
yes, a bit, nothing short-term but for LinuxCNC3. One of the tasks for L3 is to abstract and generalize the motion command and status interfaces, which really *are* messaging interfaces (command message goes to motion, status 'message comes up'). I am discussing this currently off-list but it is a complex issue especially if layered components are considered (this would mean: one component can use primitives understood by some other component, eg a hypothetical 'homing' module could generate command messages 'motion' understands and acts upon; this would enable splitting complex components into simpler, more easily exchangeable parts; HAL pins arent strong enough for that kind of component interaction). It's very easy to deadlock or livelock such a system if it's not sufficiently thought through, and consequently there are no tangible result yet. However, one thing I'm fairly sure about: components which take, or send messages will have named handlers for it, very similar to the HAL functions now. They are just not called cyclically from threads, but on demand from the 'commands down from userland, status messages up to userland' vehicle which will probably be a char device driver in the RT version and a named pipe in the SIM version. It would be the obvious mechanism to hook into for your purpose, as that vehicle must be able to transgress the userland->kernel-context->RT thread, and back, boundaries in a transparent way, without polling and with support for poll()/epoll()/select() (sidenote: deviating from the stream/file descriptor model is a capital design defect in NML/RCS, and it is pretty much unfixable). In userland, various message sources can be quite easily integrated into a 0MQ publisher, with different 'topics' - eg. one topic 'RTAPI messages', one topic 'HALstatus messages'; arbitrary subscribers could sign up to topics and get them in a uniform way. The only requirement for easy integration with 0MQ is that message availability can by notified from RTland, or Simulator land, to the publisher with a mechnims compatible with zmq_poll(3). For a named pipe, it's off-the-shelf compatible; I have an example for RTAI for compatible notification originating from an RT thread through sys_notify() on a sysfs device, which works identical except for the pathname. I assume RTLinux will have something similar, and then that mechanism should go into RTAPI in a generalized fashion. - Michael > > Chris M > > ------------------------------------------------------------------------------ > 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
