a few notes from the djungle (most of the following will only make sense to folks which have tried to understand what task does):
I've transliterated the Python mockup into C++, and switched to protobuf encoding - which at the time only means NML messages are tunneled via a protobuf wrapper. The command injection via zmq into task works fine; the key step was implementing in parallel the new (task-managed) ticket number scheme which will replace the (client-managed) 'serial' and 'echo_serial' fields (and eventually get rid of the bug Sascha reported). Thus the zmq-injected commands now use the ticket scheme, the non-converted old-style submission remains on the serial/echo_serial scheme. Flatly, the idea of using locally generated serial numbers to tag a commands in a shared memory buffer and hoping for no collisions to occur was - to put it mildly - a lapse in design to start with. As a next step I've started converting the Python linuxcnc module to alternatively use the old or the zmq scheme driven by a switch, and there are still no roadblocks to report. Nothing finished, but also no 'oh my god, how we're going to do this'. The intent is to be able to switch transports by say an environment variable and verify things still work with old and new transport. The current goal is to completely switch command submission (semi-done) and in the next step, status reporting (EMC_STAT). Once both directions are known to work for the linuxcnc module, the other candidates are due: shcom.cc which is used by a lot of code (linuxcncsh, linuxcncrsh, halui etc). The current work is a throwaway branch; it's just to figure what patterns and functional abstractions are needed. Once those are sorted, it needs to be redone properly, comprehensible error messages and all. There's one pattern emerging - at least in the task-UI interaction, and that is an overall transition from polling shared memory variables towards non-busy wait for events. In terms of programming this means that change detection moves to the entity which effects the change, and the tracking entities just listen for change updates from that originating entity. Overall I think this is a plus because polling happens only once, non-busy waits are cheaper and also the tradeoff between response time and CPU usage becomes less critical since it needs to made only once, not per-client. Using the protobuf and zmq infrastructure is really easy, and getting all Python bindings for free is a huge plus, it makes for very easy testing. The largest effort is actually to reverse-engineer the intent in some of the - sorry to say, hopelessly convoluted and really badly written code - in task and subsidiary modules. The amount of mindless copy & paste repetitive coding is appalling, and it is at times hard to stick to the goal 'no changes for now except replacing the transport and status update scheme'. A subsidiary effort is for instance making message types globally unique; since so far NML and motion messages had to be disjoint anyway due to the unsuitability of NML for kernel thread systems, nobody bothered since it was taken as a given hard restriction; this restriction is going away since we will have end-to-end messages all the way from UI to RT and back in a single format and type scheme, hence cleanup needed. Note that once conversion is done there remains no code in task which has to be C++, as Python bindings for all moving parts will be available. I would have no parting pains with the task code, and if somebody would want to redo this in Python, it is time to start thinking to bring the - sorry, pathethic - implementation of the task state machine into a comprehensible and adaptable form, for instance by using the fysom.py state machine framework. -- My feeling for the overall effort for ripping the NML transport is this can be done in a month; replacing the NML message formats will be another few weeks but simpler in nature and this can be done incrementally. So overall 'this year' for the NML/ZMQ transplant remains realistic. - Michael ps: dont worry, I sill keep an eye on the unified build branch, but as far as I'm concerned only mopup is left so I take the liberty to rebug other areas of linuxcnc now ;) ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
