On Wed, 29 Aug 2012 22:25:41 +0200, Roger Holmquist wrote: > Hello all! > > One of my reasons to join this list is because I have got an offer > to do a LinuxCNC hack about remote controlling a small cluster of > synchronized machines each driven by a copy of linuxCNC. > > The task is to design a piece of SW who will feed the machines with > G-code and to create a simple GUI so it can be managed by the > enduser. I guess it should be connected over a LAN and some > RT-critical events (parts of seconds) will maybe be synchronized over > copperwire. > Some kind of NTP-driven Watchdog/Heartbeat might be an alternative? > > Anyway, my previous experience in the RT field is with WxWorks and > other RT systems but that was 10-20 years ago... > > Right now I'm working in the CNC business in a CNC-shop doing various > tasks related to production. > > I am also doing a hack about pcb2gcode because it doesn't output in > the metric system etc... ;-) > Yes, I'm a European! > > Well, suggestions are welcome. > > / Roger
hej Roger, glad att du kunde göra det (and that's from google translate -- I don't know a word of Swedish ;-) The only LinuxCNC via Ethernet I know of is the hacked version of MiniEMC2, but others could probably tell you about efforts I am unaware of. The multiple machine coordination with overlapping work envelopes is a topic a few of us have discussed working on from time to time, but I do not think there is anything substantial been done in that arena yet. Can you tell us more about your setup and needs? Also, can you help with programming on the LinuxCNC side, or is your programming experience limited to g-code? Looking at the NTP documents and specs, it looks like under ideal circumstances it can hold 1ms in local area networks and ~10ms across the internet. With that is sounds like you would want to set up a local server, and synchronize all the machines from that. At ~1ms you should be able to easily set up a reasonable safety margin and coordinate the motions between different machines, but probably not coordinating individual axes if they are running fast (anywhere near 1m/s +). Personally, I would like to take a CAGD approach with definable work envelope semaphores or critical regions, but that's just me... Actually after thinking about it for two seconds, a semaphore into critical regions would work without the need of NTP coordinated clocks. The trick would be to set up some equivalent "move to position and wait for wait for a 'GO' signal", at which point that machine owns that space. The problem here is that the g-code would have to be aware of the critical regions. It would be better if you could analyze the motion outside of LinuxCNC and then automatically insert the entry/exit into the critical regions. I see how I could easily do that using intermediate output from the simulator, but that is getting into CAGD analytical territory and techniques. EBo -- ------------------------------------------------------------------------------ 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
