Am 25.06.2012 um 13:40 schrieb EBo: > Speaking for myself, I like Plan9 type synthetic file systems. The > Styx-on-a-Brick group used this to great advantage on their robotics > project, but I am not sure how many others here in the EMC crowd would > appreciate it. In general I think most would have two questions 1) what
Looking at http://doc.cat-v.org/inferno/4th_edition/styx-on-a-brick/ and trying to get the gist, for example Start motor... % cd motor % echo -n f7 > 0 Reverse the motor... % echo -n r7 > 0 Let’s try a blocking read on the sensor % echo b5 > 0 % cat 0 so what this does is unify state setting/reporting as well as (I guess) queued motion commands - in Linuxcnc terminology, this would amount to a common filesystem interface to HAL and motion (I guess usrmotif.c) - note that motion command interpretation is logically in the filesystem write method that idea would have two possible equivalents in linuxcnc space: 1) adding the usrmotif.c interface to motion as a filesystem name space. This interface isnt currently exposed as an API, and it is a post-G-code API. 2) exposing the emctask interface to the GUI's as a filesystem namespace. This would be a pre-G-code API, so something like 'echo 'g0 x2 y3' >linuxcnc/MDI' is conceivable. doing 1) is something I think would be valuable not only as a testing vehicle, but also as an API for non-linuxcnc/non-G-code motion applications, for which I do see use. In fact I think one of the reasons why the (otherwise great) HAL/motion combination isnt reused outside core linuxcnc lies in the fact that motion has no API for mortals. -m > does it buy EMC and 2) what will it break. If it can be done > independently, then I think you might find some more support other than > just myself, but we will see. > > If possible I would love to take a look at your code when available. > > Best regards, > > EBo -- > > On Mon, 25 Jun 2012 13:11:55 +0200, Michael Haberler wrote: >> I wanted to learn about Fuse (http://fuse.sourceforge.net/) and did a >> prototype halfs which makes the HAL namespace visible in the Linux >> filesystem. >> >> To convey the idea, a usage example: >> >> $ halfuse /tmp/hal >> $ cd /tmp >> $ ls hal/ >> components functions params pins signals threads >> $ ls hal/signals/ >> acc-ok-x spindle-pos tool-prep-loop >> Xhomeswpos Yhomesw Zpos >> ... >> >> $ ls -l hal/pins/motion.spindle-[fis]* >> --w-------. 0 root root 15 2012-06-25 12:41 motion.spindle-forward >> -rw-------. 0 root root 15 2012-06-25 12:41 >> motion.spindle-index-enable >> -r--------. 0 root root 15 2012-06-25 12:41 >> motion.spindle-is-oriented >> ... >> >> $ cat hal/signals/estop-loop >> FALSE >> $ echo 4711 > hal/pins/foo >> $ cat hal/components/l* hal/components/iocontrol >> 91 RT limit2 ready >> 94 RT lowpass ready >> 56 User iocontrol 23281 ready >> -- etc >> >> My questions are: >> >> - does this make any sense pursuing as a contribution? >> >> I'm a bit unsure about a decent use case and from understanding fuse >> (accomplished) to a useful tool (not accomplished) it's quite a bit >> of >> work >> however now that halrmt is gone, remote access to HAL has an option >> less; but whether remote file access through, say, samba, is a usable >> realtime monitoring method is TBD; I guess no due to caching. >> >> - if yes, how to proceed on HAL attributes which cannot trivially >> mapped to filesystem attributes (like mapping HAL_IN = 'r', >> HAL_OUT='w', HAL_IO='rw' as file permissions) ? >> >> for example, to determine the HAL type of a pin/signal/param, I see >> two options: using extended attributes (see man 5 attr), for instance >> 'getattr', or alternatively a shadow property tree: >> >> $ getfattr -n user.haltype hal/signals/estop-loop >> # file: hal/signals/estop-loop >> user.haltype="bit" >> >> or alternatively: >> >> $ cat hal/properties/signals/estop-loop/type >> bit >> >> >> - Michael >> >> >> >> >> >> ------------------------------------------------------------------------------ >> 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
