M
Hugh Jack wrote:
> Hi,
>
> If anybody wants to use my code, feel free.
Thanks Hugh.
> If you are trying to patch in the SMM,
> it is best to do it through the 'io.cpp' file.
Actually I was thinking of taking out all the io stuff. Maybe include it in another linuxplc module, but for now I was thinking of using only the plc5 emulator, and wrap it up as a linuxplc module. I am going to patch up the store.cpp file to write directly to the linuxplc memory.
> I am glad the discussion of the project direction is continuing. Here
> are some points that I think are worth considering.
>
> 1. It is time for the Puffin PLC to do a release. I see the basic
> elements forming up - the FAQ, some demos, etc. Why not set a target of
> a few weeks from now, and work towards it?
A few weeks is not quite realistic (I would put it until the end of the year - only 2 months to go), but I agree with you here. If we can get a
version out there for the many beta testers that seem to be lurking, maybe we will get new coders to help out.
Here is my vision for a linuxplc 0.1 version:
1) The library stays basically as it is (the online changes feature will be left for the 0.2 version, as well as support for periodic execution of modules, and support for RT Linux). From now on just clean up the code, document it, and fix the bugs we already know exist, and any other that might surface.
2) For I/O, use the modbus modules and the dio module. I haven't been following the work in these modules closely, but it seems to me they
basically require some changes to the configuring syntax to make them consistent with each other. This is not crucial, we can have the 0.1
version without this consistency.
3) For mmi, use the curses based vitrine, and write a kbd module to map keyboard keys to linuxplc points.
4) For logic engines, get the iec compiler working, make the dsp module useable, and if done on time, integrate Hugh's plc5 emulator (interpreter) into the linuxplc.
What needs to be done:
a) clean up the linuxplc library. I am willing to continue with this, if no one else is.
b) finish up the modbus modules. Philip (Costigan), do you think you could finish and document this by the end of the year?
c) Make the dio configuration syntax consistent with the modbus modules.
Anybody willing to do this?
d) Write a kbd module (copy the state of a key to a linuxplc point).
Anybody want to help out here? Harald, maybe you could make this in an evening?
e) Get the iec compiler working. David, do you think you can get it working by the end of the year?
f) Integrate Hugh's plc5 emulator into a linuxplc module. Depending on how much work this becomes, I might, or might not be able to do this, along
with cleaning up the library code. Anybody else want to help out? Hugh? Phil?
g) Get the dsp module a little further along to become useful. I am willing to work as code integrator by outsourcing the blocks. Cmon guys, I am no expert on PID modules, so please, I can't do this on my own. I really need some help here. Chetan, Rick, can you help out here please? Do you prefer writing your own PID module using you own architecture? That would also be great. We need a PID module urgently.
What do you guys think? Can we do it?
> 2. The SMM architecture of the Puffin PLC would allow any variety of
> languages to be used without impacting other modules. The best advice to
> increase development would be to release a tarball that has a simple API
> so that others can write independent applications and drivers. I would
> be very interested in including it as part of the LPC project.
I agree here. Let me just stabilize the API to the synchronisation part, and then maybe Dan could put up the tarball on an ftp server?
We could probably do this by the end of the week?
> 4.(...) The group needs to put together a clear description of
> the project with technical details and directions. (...)
Sorry, I'm not a Computer Scientist, just an electrical engineer with some programming knowledge. I don't know how to write specs. The best I can do is what was used for the introduction to the FAQ. Can anybody else help out
here?
Cheers,
Mario.
--
----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
> Hi,
>
> If anybody wants to use my code, feel free.
Thanks Hugh.
> If you are trying to patch in the SMM,
> it is best to do it through the 'io.cpp' file.
Actually I was thinking of taking out all the io stuff. Maybe include it in another linuxplc module, but for now I was thinking of using only the plc5 emulator, and wrap it up as a linuxplc module. I am going to patch up the store.cpp file to write directly to the linuxplc memory.
> I am glad the discussion of the project direction is continuing. Here
> are some points that I think are worth considering.
>
> 1. It is time for the Puffin PLC to do a release. I see the basic
> elements forming up - the FAQ, some demos, etc. Why not set a target of
> a few weeks from now, and work towards it?
A few weeks is not quite realistic (I would put it until the end of the year - only 2 months to go), but I agree with you here. If we can get a
version out there for the many beta testers that seem to be lurking, maybe we will get new coders to help out.
Here is my vision for a linuxplc 0.1 version:
1) The library stays basically as it is (the online changes feature will be left for the 0.2 version, as well as support for periodic execution of modules, and support for RT Linux). From now on just clean up the code, document it, and fix the bugs we already know exist, and any other that might surface.
2) For I/O, use the modbus modules and the dio module. I haven't been following the work in these modules closely, but it seems to me they
basically require some changes to the configuring syntax to make them consistent with each other. This is not crucial, we can have the 0.1
version without this consistency.
3) For mmi, use the curses based vitrine, and write a kbd module to map keyboard keys to linuxplc points.
4) For logic engines, get the iec compiler working, make the dsp module useable, and if done on time, integrate Hugh's plc5 emulator (interpreter) into the linuxplc.
What needs to be done:
a) clean up the linuxplc library. I am willing to continue with this, if no one else is.
b) finish up the modbus modules. Philip (Costigan), do you think you could finish and document this by the end of the year?
c) Make the dio configuration syntax consistent with the modbus modules.
Anybody willing to do this?
d) Write a kbd module (copy the state of a key to a linuxplc point).
Anybody want to help out here? Harald, maybe you could make this in an evening?
e) Get the iec compiler working. David, do you think you can get it working by the end of the year?
f) Integrate Hugh's plc5 emulator into a linuxplc module. Depending on how much work this becomes, I might, or might not be able to do this, along
with cleaning up the library code. Anybody else want to help out? Hugh? Phil?
g) Get the dsp module a little further along to become useful. I am willing to work as code integrator by outsourcing the blocks. Cmon guys, I am no expert on PID modules, so please, I can't do this on my own. I really need some help here. Chetan, Rick, can you help out here please? Do you prefer writing your own PID module using you own architecture? That would also be great. We need a PID module urgently.
What do you guys think? Can we do it?
> 2. The SMM architecture of the Puffin PLC would allow any variety of
> languages to be used without impacting other modules. The best advice to
> increase development would be to release a tarball that has a simple API
> so that others can write independent applications and drivers. I would
> be very interested in including it as part of the LPC project.
I agree here. Let me just stabilize the API to the synchronisation part, and then maybe Dan could put up the tarball on an ftp server?
We could probably do this by the end of the week?
> 4.(...) The group needs to put together a clear description of
> the project with technical details and directions. (...)
Sorry, I'm not a Computer Scientist, just an electrical engineer with some programming knowledge. I don't know how to write specs. The best I can do is what was used for the introduction to the FAQ. Can anybody else help out
here?
Cheers,
Mario.
--
----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc