Rafael Skodlar wrote: >> I think that this suggestion would work here too, because it was >> mentioned that running EMC on a virtual machine will have enormous >> jitter. With all due respect to members of EMC community, I doubt that >> we can fix that, so I think that Your second suggestion on >> virtualization is denied. >> > Denial can only relate to current state of the (EMC) art. I simply > listed an option that has been implemented in commercial embedded > systems software. > > VM running on a dedicated CPU core independently under RT micro kernel: > http://www.enea.com/Templates/Product____27035.aspx > > http://industrial-embedded.com/virtualization-platforms-real-time-embedded-systems > > Under Application examples: "the manufacturer can run the legacy > real-time software on one core in a multicore processor and implement > the new user interface functionality on the remaining cores. The VMM in > this case partitions the processor‚ I/O, memory, and other resources to > ensure that only the machine control software has direct access to the > motion control hardware and that it operates on a dedicated CPU core. > This creates a separation between the real-time OS and the user > interface software, avoiding interference between the two OSs and > thereby protecting the timing loops the legacy real-time software > manages from being violated by operations the new human interface > software performs." > > Today's motherboards come with multi core CPUs and it's a shame we > cannot use one or more cores for EMC under tight RT constraints and GUI > part of application in another one. > That's precisely what EMC does when you use isolcpus on the kernel boot command line. In any case, I believe the EMC RT processes all bind to the highest CPU number (so if you have a 4-core, isolcpus should be 3). This isn't what was originally asked though. The original question was in regard to running multiple instances of the motion controller.
You can already run multiple GUIs and other userspace programs in parallel, but they can only connect to the single instance of the realtime motion and I/O controllers. >> I think that instead of trying to reinvent the wheel and run several >> instances of EMC on a single PC and getting into trouble of >> synchronizing them, I think that investigating the option of expanding >> current capabilities of interpreter and adding few more axes might be >> easier. >> > Agree. This is the interim solution. > It's probably not the interpreter that needs improvement, actually. HAL can handle as many actuators as you want (subject to some execution time limits that nobody has come close to yet). One could easily write a very very simple motion control HAL component, which can have multiple instances. This might be something like a limit3 that takes into account multiple inputs simultaneously. If there were a userspace component to feed positions (think like halsampler/halstreamer or something), then you'd be all set. This is probably closer to what the original question was, since it's unlikely that any pick&place machine cares what the next one is doing. It's also not necessary to use G-code to command a pick&place - it only needs 2(.5)D coordinated motion and some I/O. - Steve ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
