Custom software running in general purpose OS

We are evaluating delta tau PPMAC for one of our applications. We have an existing software framework consisting of distributed Java/C++ components running on Linux (CentOS 5.5) platforms. One of the reasons the PPMAC appeals to us is the fact that it runs Linux, and therefore the possibility of having one of our components run in the PPMAC general purpose OS communicating directly with the motion controller. This would be different than the standard approach of having the component running on another machine and communicating with the PPMAC using ASCII commands over Ethernet. This C++ component would be responsible for submitting motion requests and watching for completion/limit/error events. It would then report these events back to other components in the framework running on different machines. Here are some of our concerns: 1) Components running in our framework communicate using ICE middleware. Do you see any issues running ICE on PPMAC Linux general purpose OS? 2) Component running in our framework access persistent store using PostgreSql client. Do you see any issues running this client software on PPMAC general purpose OS? 3) The big question is if we run a C++ component in the PPMAC general purpose OS, will it be able to communicate with the PPMAC motion controller via the C API? 4) Does PPMAC use interrupts when end of motion/limit/errors occur? If so could our component running in the general purpose OS register an interrupt handler for these or are they reserved for the RTOS only? Sorry or all the questions...running our s/w on the controller is a new direction for us and we are unsure of the PPMAC Linux capabilities. Cheers!

Let me answer questions 1 & 2 together with a blanket statement. If an application runs on a general purpose linux and has been written properly it will work on our system. Our powerpmac uses an embedded linux kernel 2.6.30 with the xenomai patch and the filesystem is debian. Linux applications when compiled for our system will operate. Often the packages have been precompiled and if you setup the powerpmac to talk to the internet you issue apt-get install {package name} to install the software. Our system mounts the file system readonly, so there are a couple of minor tricks to make filesystem writable but that is no big deal. It is not a problem for a C++ application to communicate to our C API. C++ talking to a C .so shared library is not a problem. You can have user written servos and user written phase routines that our kernel driver calls every phase interrupt or servo interrupt. So your own custom function is callable by our motion engine. Our driver is in control of the ISR [quote='andyf' pid='487' dateline='1278027479'] We are evaluating delta tau PPMAC for one of our applications. We have an existing software framework consisting of distributed Java/C++ components running on Linux (CentOS 5.5) platforms. One of the reasons the PPMAC appeals to us is the fact that it runs Linux, and therefore the possibility of having one of our components run in the PPMAC general purpose OS communicating directly with the motion controller. This would be different than the standard approach of having the component running on another machine and communicating with the PPMAC using ASCII commands over Ethernet. This C++ component would be responsible for submitting motion requests and watching for completion/limit/error events. It would then report these events back to other components in the framework running on different machines. Here are some of our concerns: 1) Components running in our framework communicate using ICE middleware. Do you see any issues running ICE on PPMAC Linux general purpose OS? 2) Component running in our framework access persistent store using PostgreSql client. Do you see any issues running this client software on PPMAC general purpose OS? 3) The big question is if we run a C++ component in the PPMAC general purpose OS, will it be able to communicate with the PPMAC motion controller via the C API? 4) Does PPMAC use interrupts when end of motion/limit/errors occur? If so could our component running in the general purpose OS register an interrupt handler for these or are they reserved for the RTOS only? Sorry or all the questions...running our s/w on the controller is a new direction for us and we are unsure of the PPMAC Linux capabilities. Cheers! [/quote]