Getting ready for the first release!

M

Thread Starter

Mario de Sousa

1 - a tcl demo. This already exists in the demo/basic directory,
just needs re-organizing into an independent basic_tcl directory.

DONE!

2 - get the modbus modules to compile, i.e. include the function
that was in the old io.c file into the modbus source files.

Philip, I have now inserted the plc_io_status_pt() function
in the generic io library. The modbus modules will still not
compile because they do not conform to the io_hw.h interface.
Are you working on this? If you have any questions,
don't be afraid to ask!

3 - a modbus demo explaining how to configure the module.

Waiting for point 2.

4 - Debug the filtering blocks of the dsp module.

I think we should make the release without this!

5 - have the dio48 module use the new generic io library
6 - a demo directory for the dio48 module
This module is working. We can make the release with the
module as it is and change it later. We'll see if
time allows to do the above before the release.


7 - A user manual, probably in html format.
Curt, do you need help with this?

8 - a demo directory for the il compiler (e.g. implement the chaser
in il).

DONE!

9 - A top level makefile that will make each module, and install
the libraries and executables into apropriate directories,
i.e. get all the executables into a single directory (probably
with sub-directories for io moduls, logic modules, utilities, ...)

Jiri, I know you don't agree with this, but I think if we are
going to make a release we should try and keep to the
sugestions in the Software Release Practice HOWTO
http://www.linuxdoc.org/HOWTO/Software-Release-Practice-HOWTO/index.html
Do you think you could help out here? The top level makefile should
probably also have a make install that installs the plc libraries
in the apropriate directories (/usr/lib).
What I would really like to see is a top level make release
that would make a tar.gz release file. The HOWTO has some
demo code for the makefile to do this. Could you look into
this? Once we have this, we can make releases more often.

10 - A big demo, with some nice graphics, and realistic processes...

Juan, how are you coming along with this?
Do you have any questions?

11 - finish lib/util/puffinplc.c so that it can wait for a quit point,
and
then eliminate the demo/*/demo perl scripts. They were quick and dirty
hacks to begin with and should die (I can say that, I wrote them).

Jiri, I would like to do this properly from the start.
We need to think about this before we go charging ahead.
Do you have any ideas offhand we could start discussing?
Once we get the first release out the door,

Cheers,

Mario.

--
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
P

Philip Costigan

On Fri, 8 Jun 2001 19:37, you wrote:

> 2 - get the modbus modules to compile, i.e. include the function
> that was in the old io.c file into the modbus source files.
>
> Philip, I have now inserted the plc_io_status_pt() function
> in the generic io library. The modbus modules will still not
> compile because they do not conform to the io_hw.h interface.
> Are you working on this? If you have any questions,
> don't be afraid to ask!
>

Yes I have had a look at it but I am finding it difficult to find time to really put a good effort behind it.

I tried to take the cif code as a base. I couldn't grasp what I had to do to change the existing modbus code to meet the same style and method as to achieve a compilable and running system.

I think help is required. (maybe a rewrite. argh.)

Sorry if this is coming a bit late, I should have said something earlier.

>
> 3 - a modbus demo explaining how to configure the module.
>
> Waiting for point 2.
>

Hmmm?
I think we will do this when it all works again.

--

Regards

Philip Costigan



_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Juan Carlos Orozco

Mario,

About the point 10 - big demo,

I had serious difficulties running LinuxPLC in RedHat 7.0. I could not find the console-tools-dev equivalent. I tried the smm-mgr -g and I am getting a lot of "Error initializing the plc" messages. For now I gave up trying with RedHat 7.0 because debian seemed to work easier.

With the Corel Linux 1.2 (slink debian) things worked better except for the vitrine that did not run. Since debian seemed to work better I decided to get the current stable version of debian (potato). Things worked beautifully with this linux, the demos worked very well. Except for the tcl demo that has a known bug in potato (I just could not figure out the workaround) when
compiling /lang/tcl and running ./configure I get a message saying that int could not find tcl configuration definitions. Any way I am not planning to use tcl for the moment so this is not a problem for now.

I finish installing debian potato yesterday so I am barely starting with the demo. I have some documents on the project and want to start trying some modifications on the basic demos, I will base my project on the basic_dsp demo since my project has some PIDs in it. By the way what is the graph part of the vitrine in the basic_dsp demo supposed to do? On my computer it just
moves a couple of + to the right or to the left as I type 0-9. The two + signs move together. Taking a second look to the vitrine.conf I may have found the answer myself, it seems there is a typo, in the last line it should be out_1 instead of out_f32 for the x_plc_pt and y_plc_pt. One more
thing, when exiting from the demo my terminal does not make a correct carriage return any more which makes it useless. I need to start a new
terminal after exiting vitrine.

I will keep the group informed of my progress. There may be some things that I am experiencing that is happening to others. For example my RedHat 7.0 problems. Or my debian slink problems with vitrine. Also, when I installed debian potato from the debian official CD image 1 I still needed to write the next commands: apt-get install console-tools-dev, apt-get install cvs,
apt-get install libtool, apt-get install libncurses5-dev to be able to download (cvs) the project and compile the demos. Before using apt-get I needed to edit the /etc/apt/sources.list to get the files from internet. Of course debian has to be configured to connect with internet which is another story.

Regards,

Juan Carlos Orozco

ACElab Industrial Automation
[email protected]
www.ace-lab.com


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Mario de Sousa wrote:

>
> 1 - a tcl demo. This already exists in the demo/basic directory,
> just needs re-organizing into an independent basic_tcl directory.
>
> DONE!
>
> 2 - get the modbus modules to compile, i.e. include the function
> that was in the old io.c file into the modbus source files.
>
> Philip, I have now inserted the plc_io_status_pt() function
> in the generic io library. The modbus modules will still not
> compile because they do not conform to the io_hw.h interface.
> Are you working on this? If you have any questions,
> don't be afraid to ask!
>
> 3 - a modbus demo explaining how to configure the module.
>
> Waiting for point 2.
>
> 4 - Debug the filtering blocks of the dsp module.
>
> I think we should make the release without this!
>
> 5 - have the dio48 module use the new generic io library
> 6 - a demo directory for the dio48 module
> This module is working. We can make the release with the
> module as it is and change it later. We'll see if
> time allows to do the above before the release.
>
>
> 7 - A user manual, probably in html format.
> Curt, do you need help with this?

Yes. I have an accelerated time line for cell deployment that is eating all my time. I need to do it because it's a Linux powered cell and it's
politically crucial that it be deployed on time and perform flawlessly. I'm sure you all can understand why. This cell project was on the rocks and very close to cancellation. Should make a good case study if I survive. I'll do what I can but I can't really predict when I'll have free time. That's what you get for looking good in simulation and developing in 70% less time. Yin and Yang

Regards

cww


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

Mario de Sousa wrote:
> 11 - finish lib/util/puffinplc.c so that it can wait for a quit point,
> and
> then eliminate the demo/*/demo perl scripts. They were quick and
> dirty
> hacks to begin with and should die (I can say that, I wrote them).
>
> Jiri, I would like to do this properly from the start.
> We need to think about this before we go charging ahead.
> Do you have any ideas offhand we could start discussing?
> Once we get the first release out the door,
>

Jiri,

What I meant above is that I don't like the idea of using a user-space plc_point to control the current state of the plc.

I have been thinking a couple of minutes about this and at the moment what seems most clean to me would be to create a 'state' library used to control the state of the plc.

This library can have a global variable in the cmm for the global state of the plc (stop, run, going_down, coming_up, ...?). Each of the
modules would also have an independent state variable (run, stop, update, ....).

We can then have a command line utility to change the state of these variables, and every module would then respect their state.

I would start off with five states for the PLC:
- starting (modules are being launched, system is being setup...)
- stop (modules have been launched, but PLC is stopped)
- run (modules are allowed to run)
- stopping (going from start to stop. This takes some time because we have to wait for every module to stop.)
- quiting (system is being shutdown.)

Possible state changes are:

starting -> stop -> run -> stopping --
| ^ |
| | |
| -----------------------
|
quiting <----



Modules could have three states:
- disabled (stopped. Does not run, even if PLC is in run state)
- enabled (will run if PLC is in run state.)
- updating (module is being updated online. This tells the current process to stop running. The new process will start runing and change the state back to enabled. Disabled modules do not go through this state.)

There are still details that have to be thought out. For example, what happens to modules that do not necessarily run in a loop? How do we controll their state if they don't call the handles
plc_scan_beg() and plc_scan_end() ?

We'll probably have to implement it using user signals to signal state changes.


Comments? Ideas?


Cheers,

Mario.


--
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

Philip Costigan wrote:
>
> I tried to take the cif code as a base. I couldn't grasp what I had to do to
> change the existing modbus code to meet the same style and method as to
> achieve a compilable and running system.
>
> I think help is required. (maybe a rewrite. argh.)
>

Yes, you will need a rewrite. But most probably the rewrite will consist mainly of deleting code that is now replaced by the io library. I think
very little new code will have to be written.

The basic idea is that you no longer have to write a module. The io library already is a complete io module. You only have to supply the
functions for the io library to access the hardware, in other words you basically have to write the functions that compose the modbus
messages and send them out over the wire. You already have these! They merely have to be molded to conform to the interface the io library
expects. That interface is described in the io_hw.h file.

Let me repeat the functions here, and explain what you most probably have the code do in each of them...
Just remember that all the functions should return 0 on success, and -1 on failure.

*********
int io_hw_write(io_addr_t *io_addr, u32 value);

This function should write the value to the register whose address
is in *io_addr. What you really have to do is send a modbus write
message. The destination address is stored in the *io_addr variable.
The value to write is given in the value variable.
The format of the *io_addr variable is defined by you, as
long as it does not take more than 8 bytes. So you can use for e.g. 1
byte for the device, 2 bytes for the address within the device, and
another byte to identify the memory area (input, output, memory,
counter, timer, ...) The remaining bytes can go un-used.


********
int io_hw_read (io_addr_t *io_addr, u32 *value);

Similar to previous function, but read instead of write!


*********
int io_hw_write_end(void);

This is called once all the writes have been called.
For your io module, this is an empty function!
{return 0;}

int io_hw_read_end (void);
Similar to previous. Just use an empty function...
{return 0;}



**********
int io_hw_write_array(io_addr_t *io_addr, int count, void *opaque_ptr);
int io_hw_read_array (io_addr_t *io_addr, int count, void *opaque_ptr);
The above functions have NOT YET been IMPLEMENTED in the io
library, so you don't have implement them either. It is probably a good
idea not to, as their interface might change when they do get
implemented!



********
int io_hw_parse_io_addr(io_addr_t *io_addr,
char *addr_stri,
dir_t dir,
int pt_len);
This is the third function you must really write.
It must parse the io address described in the string, and
store it in the io_addr struct.
Remember, YOU define the accepted syntax in the string,
AND the internal structure of the *io_addr variable.
You can use the dir and pt_len variables as
consistency checks, if required, but you may also
simply ignore them!
The dir says if it is input (read) or output (write).
The pt_len gives you the number of bits of the plc_pt
that will be written to the referenced location.


*********
int io_hw_parse_config(void);
This is the fourth function you must write.
This is the first function that gets called, and is called only once.
You will probably have to parse the config file here, and read in a table of the devices you will have to interface to, and their IPs or hostnames (in the case of modbus tcp).


*****************
int io_hw_init(void);
Here you initialise the access to the hardware, if any.
In your case, you will probably create and connect a socket for each device configured in the table that was parsed by the previous function. For non modbus, you will probbaly initialise the access to the serial port, configure the baudrate, etc...


*************
int io_hw_done(void);
Terminate access to the hardware.
Close all the sockets, ....
Restore status of serial port, ....


****************
char *IO_MODULE_DEFAULT_NAME = "modbus_xxx";
The above is merely a variable with the default name the module should use.


****************
int io_hw_dump_config(int debug_level);
this is only used for debugging. You can leave it empty...
{return 0;}

char *io_hw_ioaddr2str(io_addr_t *io_addr);
Same as above...


As always, if you have any questions, don't hesitate to ask...

Cheers,

Mario.


--
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

Curt Wuollet wrote:
> > 7 - A user manual, probably in html format.
> > Curt, do you need help with this?
>
> Yes. I have an accelerated time line for cell deployment that is eating
> all my time. I need to do it because it's a Linux powered cell and it's
> politically crucial that it be deployed on time and perform flawlessly.
> I'm sure you all can understand why. This cell project was on the rocks
> and very close to cancellation. Should make a good case study if I survive.
> I'll do what I can but I can't really predict when I'll have free time.
> That's what you get for looking good in simulation and developing in
> 70% less time. Yin and Yang
>

No wories. We don't have any deadlines!!! :)

In any case, is there anybody who would like to help out here? There is plenty written already, but things are dispersed among several files, FAQ, etc...

We need somebody to organise all this and make a comprehensive document.

I seem to remember more than one person willing to help out here some time ago? Is this still the case?

Cheers,

Mario.


--
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
another head first newbie...
I too have been watching this project for a quite some time. I currently program Mitsubishi FX2N's at work.

As an end user, Where could i get a list of targeted hardware?

Is there an option (future?) to compile STL programs to PIC or AVR microcontrollers?

Ken Wood

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Hi guys,

One thing I have seen done is that your modules will have pre-defined function calls such as "Start_Driver()" or "Unload_Driver()" and when the main module wants to run these it links to these functions (at compile, not dynamic) and executes them when it wants to. Therefore you have a master module that controls all of this stuff and the other modules don't have to synch or poll these states if they are not in a loop. I guess this is similar to how kernel modules work and get loaded, etc.

~Ken

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Curt,

You should have waited to show your similation until the rest of the project was 90% finished!! :eek:) I am in the process of getting a demo ready for work, but I want to have a lot of the unknowns over with before presenting it. Good luck on it. Getting over the political stuff seems like a pain but it is crucial.

BTW, I wanted to thank you for one of your previous emails about how open source and linux development can benefit a project. (This was several weeks back). I showed it to some of my people at work and they were reading every line and saying "Yeah, I hate it when software companies do that" etc etc. One more data point for helping to get our controllers here to a linux brew ....

:eek:)

~Ken

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi Ken

In the heat of the current battle, we should never forget the larger war. My desk, my shop, my company ------> the world :^)
Never mind, It's Friday afternoon, the robot puked, I'm pretty crisp around the edges. I'm gonna go shooting on the way home, very therapeutic and relaxing. Then it's back to work.

Regards

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri:
> > 11 - finish lib/util/puffinplc.c so that it can wait for a quit point,
> > and then eliminate the demo/*/demo perl scripts. They were quick and
> > dirty hacks to begin with and should die (I can say that, I wrote
> > them).

Mario:
> > Jiri, I would like to do this properly from the start. We need to
> > think about this before we go charging ahead.

Mario:
> What I meant above is that I don't like the idea of using a user-space
> plc_point to control the current state of the plc.

The other side of the coin is creating a completely new interface that will need to duplicate much of the functionality of the existing interface... We'll then have to add this interface into all the programming languages we
support, so that stepladder can stop the PLC etc.

> I have been thinking a couple of minutes about this and at the moment
> what seems most clean to me would be to create a 'state' library used to
> control the state of the plc.

Personally, for the first release, I'd just put in the quit point; it won't be that big a problem to make a backwards-compatibility function once the library is written (if it will even be needed) - just wait for the point then call the state library.

I'm worried that to do a state library properly will take some time...

(Another reason would be that it's a minimal change from the status quo - just implements those perl scripts a bit more sensibly.)

Jiri
--
Jiri Baum &lt;[email protected]>
"In my opinion, the GPL is optimized to build a strong software community at the expense of a strong commercial software business model."
--Craig Mundie, Senior VP, Microsoft; 17 May 2001

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top