C
Hi all
Just a line or three as a status update and a little look ahead.
I received the CIO-DIO48 card from Computerboards (thanks again to Heartland Engineering) and am trying to get "in the zone" to envision how to proceed. I haven't been able to concentrate much because of the other things that are going on. I spent considerable time during the week getting a hack together for the Optilogic Ethernet I/O and had some modest success by the end of Friday talking to it. The product is new and there have been some problems with the proto documentation. Adding that to my uncertanty about whether I was doing the UDP correctly or not, and I burned a lot of cpu time on compiles. I now have examples of packet data which are much more definite than the specs. I am all primed for progress in the
upcoming week. The DIO48 is fairly familiar as I have used compatible hardware in the test
equipment HE sells. So, all I need is time and that's going to be at a premium this week. I've
been pressed into service for a mission critical IS project for Westling, the parent company of
Heartland. We are in process of purchasing a new Factory/ERP system and doing due diligence and
justification to run that system on, you guessed it, Linux! I had folks from Pioneer out to source a Compaq AlphaServer and will be traveling this week to deal with software issues. So, even if it slows progress on the Linux PLC, it is time spent in a worthy cause.
I haven't seen much discourse on how we structure an I/O process and will be thinking that through while I'm away from the hardware.
Main topics:
The DIO48 needs to be configured before use. Not as much as some other devices, but we do need to set modes, designate which pins are outputs and which are inputs, get the MM names we will be mapped to and such.
Where do we keep that config info?
Do we allow runtime changes to the mapping?
Do we divide the IO process into a generic part and device specific parts?
If so, what should the interface look like.
How do we make the process aware of the mapping?
I'm kinda keeping the Optilogic stuff going in parallel so the process stays general enough to accomodate userland drivers as well.
Regards
cww
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
Just a line or three as a status update and a little look ahead.
I received the CIO-DIO48 card from Computerboards (thanks again to Heartland Engineering) and am trying to get "in the zone" to envision how to proceed. I haven't been able to concentrate much because of the other things that are going on. I spent considerable time during the week getting a hack together for the Optilogic Ethernet I/O and had some modest success by the end of Friday talking to it. The product is new and there have been some problems with the proto documentation. Adding that to my uncertanty about whether I was doing the UDP correctly or not, and I burned a lot of cpu time on compiles. I now have examples of packet data which are much more definite than the specs. I am all primed for progress in the
upcoming week. The DIO48 is fairly familiar as I have used compatible hardware in the test
equipment HE sells. So, all I need is time and that's going to be at a premium this week. I've
been pressed into service for a mission critical IS project for Westling, the parent company of
Heartland. We are in process of purchasing a new Factory/ERP system and doing due diligence and
justification to run that system on, you guessed it, Linux! I had folks from Pioneer out to source a Compaq AlphaServer and will be traveling this week to deal with software issues. So, even if it slows progress on the Linux PLC, it is time spent in a worthy cause.
I haven't seen much discourse on how we structure an I/O process and will be thinking that through while I'm away from the hardware.
Main topics:
The DIO48 needs to be configured before use. Not as much as some other devices, but we do need to set modes, designate which pins are outputs and which are inputs, get the MM names we will be mapped to and such.
Where do we keep that config info?
Do we allow runtime changes to the mapping?
Do we divide the IO process into a generic part and device specific parts?
If so, what should the interface look like.
How do we make the process aware of the mapping?
I'm kinda keeping the Optilogic stuff going in parallel so the process stays general enough to accomodate userland drivers as well.
Regards
cww
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
