Modbus/tcp works on the lplc repository

P

Thread Starter

Philip Costigan

Hi all,

I just got the Modbus/TCP to lplc interface code to work.

Its still a bit messy and I havent documented much yet but I got it to work :)

Unfortunately the program needs to have two config files. linuxplc.conf and ioserver.conf. and tag names in both have to match. Its still early days yet that we could mayby combine the two into linuxplc.conf.

The code that I wrote has a toggling bit in it that drives an output that I was testing on and off. Make sure you remove that code when you try driving real io.

I have not studied any perl but I borrowed the perl script from demo/basic and tryed to modify it. Can someone fix it up a bit to make it more friendly.

Let me know if this is what we are after or if its not quite the direction the lplc code should be like.

enough said.

Phil.


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

> Unfortunately the program needs to have two config files. linuxplc.conf
> and ioserver.conf. and tag names in both have to match. Its still early
> days yet that we could mayby combine the two into linuxplc.conf.

Yes - I'll have a look at it sometime when it's not quarter to three in the morning :)

Basically, the contents of ioserver.conf would go into a section in linuxplc.conf (perhaps [modbus]) and the data would be space-separated
instead of comma-separated.

I'll either have to add a keyword to the front of each line, or put the din/dout first. Which do you prefer? The only functional difference is that
with din/dout first the relative order of inputs and outputs in the config is discarded.

BTW, any reason for the "comment" field? In the example it basically duplicates the point full name, so I'm not sure of the reason for it...
What function does it serve?

> I have not studied any perl but I borrowed the perl script from
> demo/basic and tryed to modify it. Can someone fix it up a bit to make it
> more friendly.

Actually, there needs to be a generic way of starting up a linuxPLC, because there'll always be a collection of processes to be run, plus setup
and shutdown. It shouldn't be a perl script but rather a C program that runs according to a section in linuxplc.conf


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

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

Philip Costigan

> I'll either have to add a keyword to the front of each line, or put the
> din/dout first. Which do you prefer?

The keyword seems to be a nicer idea.

>The only functional difference is that
> with din/dout first the relative order of inputs and outputs in the config
> is discarded.
>
>
> BTW, any reason for the "comment" field? In the example it basically
> duplicates the point full name, so I'm not sure of the reason for it...
> What function does it serve?

When I originaly started coding, lplc was going to read a map from the ioserver in a file created by the ioserver. But as I learnt more about lplc's structure it became apparent that the idea had a few flaws. I just haven't removed the idea or the code completely away yet.

>
> > I have not studied any perl but I borrowed the perl script from
> > demo/basic and tryed to modify it. Can someone fix it up a bit to make it
> > more friendly.
>
> Actually, there needs to be a generic way of starting up a linuxPLC,
> because there'll always be a collection of processes to be run, plus setup
> and shutdown. It shouldn't be a perl script but rather a C program that
> runs according to a section in linuxplc.conf

Bewt, I would prefer that.
( but who is going to develop it ? )

Regards

Phil

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri Baum:
> > I'll either have to add a keyword to the front of each line, or put the
> > din/dout first. Which do you prefer?

Philip Costigan:
> The keyword seems to be a nicer idea.

OK.

> > BTW, any reason for the "comment" field? In the example it basically
> > duplicates the point full name, so I'm not sure of the reason for it...
> > What function does it serve?

> When I originaly started coding, lplc was going to read a map from the
> ioserver in a file created by the ioserver. But as I learnt more about
> lplc's structure it became apparent that the idea had a few flaws. I just
> haven't removed the idea or the code completly away yet.

OK; I'll probably remove it while I'm converting the code to use the linuxplc.conf library.

> > > I have not studied any perl but I borrowed the perl script from
> > > demo/basic and tryed to modify it. Can someone fix it up a bit to
> > > make it more friendly.

> > Actually, there needs to be a generic way of starting up a linuxPLC,
> > because there'll always be a collection of processes to be run, plus
> > setup and shutdown. It shouldn't be a perl script but rather a C
> > program that runs according to a section in linuxplc.conf


> Bewt, I would prefer that.
> ( but who is going to develop it ? )

Aye, there's the rub :)

But eventually it has to exist, it's only a matter of time.


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

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

Mario J. R. de Sousa

Jiri Baum wrote:

> Jiri Baum:
> > > I'll either have to add a keyword to the front of each line, or put the
> > > din/dout first. Which do you prefer?
>
> Philip Costigan:
> > The keyword seems to be a nicer idea.
>
> OK.

What with all the XML debate going on, I was thinking of creating an intermediate API to access the plc config file. Like this we could easily change the backend parser code without having to go through every module code. Granted, we could do this and keep the existing API, but I don't really like the names currently being used (conffile_get_value(...) etc...).
I would like to suggest we keep the existing functions and semantics, but change the names of these functions to something like plc_conf_get_value(...), etc...

Unfortunately I won't be able to do it this week as I'm off on a trip. I'll probably only be back online next monday.

Does anybody see any drawbacks to these changes?


> > > Actually, there needs to be a generic way of starting up a linuxPLC,
> > > because there'll always be a collection of processes to be run, plus
> > > setup and shutdown. It shouldn't be a perl script but rather a C
> > > program that runs according to a section in linuxplc.conf
>
> > Bewt, I would prefer that.
> > ( but who is going to develop it ? )
>
> Aye, there's the rub :)
>
> But eventually it has to exist, it's only a matter of time.
>

I've been thinking for quite some time of adding this piece of code to the smm-mgr but other stough has been coming in the way. The -g command line option would first init the common shared memory resources, and then launch modules configured in the config file. Using the smm-mgr code already written, this shouldn't take long, but this has been on the back burner for some time. Maybe it's time I do it, but as I said, it won't be this week.

BTW, I sugest we change the name of the smm-mgr to plc-mgr. What does everybody think?

Another suggestion, seeing there are more people producing code now, is that we move the utility function files (sin_util.c, sem_util.c, ...) to a common directory, so other modules may use them if required. They can also be used from the smm directory, but I would like to keep the public interface to the smm directlory limited to the plc.h file.

Mario.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> Jiri Baum:
> > > I'll either have to add a keyword to the front of each line, or put
> > > the din/dout first. Which do you prefer?

> Philip Costigan:
> > The keyword seems to be a nicer idea.

Jiri Baum:
> OK.

Done - the keyword is "tag" (not a particularly good keyword, but I couldn't think of anything better right now).

I hope I haven't broken anything - I don't have a modbus device, so I can't really test it.

I've put in a couple of comments marked "XXX" that probably deserve attention.

Both make_tag() and tagcmp() read the tag information from the config; I think it would be cleaner if add_tag() did that (or called a separate function for it) and then passed the half-filled-in struct to make_tag() and tagcmp(). I didn't change that just in case there was a good reason to do it this way, but it should probably be changed.


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

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

Philip Costigan

On Mon, 18 Sep 2000, you wrote:
>
> Done - the keyword is "tag" (not a particularly good keyword, but I
> couldn't think of anything better right now).
>
> I hope I haven't broken anything - I don't have a modbus device, so I can't
> really test it.
>

For some reason plc_init() gets cought in an endless loop. ????

> I've put in a couple of comments marked "XXX" that probably deserve
> attention.

Its ok for now. I'll drag out some books and workout what Min and Max should be.

> Both make_tag() and tagcmp() read the tag information from the config; I
> think it would be cleaner if add_tag() did that (or called a separate
> function for it) and then passed the half-filled-in struct to make_tag()
> and tagcmp(). I didn't change that just in case there was a good reason to
> do it this way, but it should probably be changed.
>

tagcmp() is designed to check that each tag is unique and that each ip - unit - point address is unique also. I think it pays to check this
collision before creating the struct. I suppose if we put our heads together we can come up with a better method.

Phil

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri Baum:
> > I hope I haven't broken anything - I don't have a modbus device, so I
> > can't really test it.

Philip Costigan:
> For some reason plc_init() gets cought in an endless loop. ????

Oops, that shouldn't happen. I'll have a look at it tonight.

> > Both make_tag() and tagcmp() read the tag information from the config;
> > I think it would be cleaner if add_tag() did that (or called a separate
> > function for it) and then passed the half-filled-in struct to
> > make_tag() and tagcmp(). I didn't change that just in case there was a
> > good reason to do it this way, but it should probably be changed.

> tagcmp() is designed to check that each tag is unique and that each ip -
> unit - point address is unique also. I think it pays to check this
> collision before creating the struct. I suppose if we put our heads
> together we can come up with a better method.

Yes, but it means that tagcmp separately re-parses the line for comparison with each existing tag.

I would suggest creating the struct first, but not putting it in the list and not filling in the next/prev fields. Then we can do the tagcmp() thing and any other checks, and if they succeed we put the struct into the linked list and fill in whatever's not done yet. Otherwise we discard it - no harm done.

The other reason I'm unhappy with the current arrangement is that tagcmp() and make_tag() do different syntax checking. I think the original versions even used different delimiters! It would be better if it were in only one place in the code, and it'd be more efficient if it were done only once.


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

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

Philip Costigan

On Tue, 19 Sep 2000, you wrote:
> Jiri Baum:

> > tagcmp() is designed to check that each tag is unique and that each ip -
> > unit - point address is unique also. I think it pays to check this
> > collision before creating the struct. I suppose if we put our heads
> > together we can come up with a better method.
>
> Yes, but it means that tagcmp separately re-parses the line for comparison
> with each existing tag.
>
> I would suggest creating the struct first, but not putting it in the list
> and not filling in the next/prev fields. Then we can do the tagcmp() thing
> and any other checks, and if they succeed we put the struct into the linked
> list and fill in whatever's not done yet. Otherwise we discard it - no harm
> done.
>
> The other reason I'm unhappy with the current arrangement is that tagcmp()
> and make_tag() do different syntax checking. I think the original versions
> even used different delimiters! It would be better if it were in only one
> place in the code, and it'd be more efficient if it were done only once.

YES.


I'll see what I can do. :-}


Phil.


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

Philip Costigan

I tested the ioserver today and it seems OK with the linuxplc.conf etc.
However when I used plctest the following happened.

$ plctest -s mcn1runlmp -v 1
Initializing the PLC.
Getting point handle.
Got valid handle to mcn1runlmp.
mcn1runlmp = 0

Shouldn't mcn1runlmp = "1" not "0". Have I done somthing wrong or has the smm code been broken?

Phil

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

Mario J. R. de Sousa

Hi Phil,

I fell for that one myself, even though I wrote plctest.

What happens is that plctest runs with module name set to "TEST" by default, so it doesn't have write permission on the point you are trying to write to.

Try

$ ./plctest -s mcn1runlmp -v 1 --PLCmodule=ioserver


Regards,

Mario.


Philip Costigan wrote:

> I tested the ioserver today and it seems OK with the linuxplc.conf etc.
> However when I used plctest the following happened.
>
> $ plctest -s mcn1runlmp -v 1
> Initializing the PLC.
> Getting point handle.
> Got valid handle to mcn1runlmp.
> mcn1runlmp = 0
>
> Shouldn't mcn1runlmp = "1" not "0". Have I done somthing wrong or has the smm
> code been broken?
>
----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------


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

Mario J. R. de Sousa

> I fell for that one myself, even though I wrote plctest.
>
> What happens is that plctest runs with module name set to "TEST" by default, so
> it doesn't have write permission on the point you are trying to write to.
>

Sorry, let me correct that.

The default module name is "test" and _not_ "TEST"


Mario.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Philip Costigan:
> I tested the ioserver today and it seems OK with the linuxplc.conf etc.
> However when I used plctest the following happened.

> $ plctest -s mcn1runlmp -v 1
> Initializing the PLC.
> Getting point handle.
> Got valid handle to mcn1runlmp.
> mcn1runlmp = 0

> Shouldent mcn1runlmp = "1" not "0". Have I done somthing wrong or has the
> smm code been broken?

In view of Mario's explanation (which I've seen but don't have handy), I've changed plctest so that it says whether it got a read-only point or a
read-write one.

So the above transcript becomes:

$ plctest -s mcn1runlmp -v 1
Initializing the PLC.
Getting point handle.
Got valid handle to mcn1runlmp - 1-bit read-only point.
mcn1runlmp = 0


While I was in the code, I also made a plc_pt_null() function, which returns the point-handle equivalent of /dev/null. It's a one-liner.

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

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

Philip Costigan

On Tue, 19 Sep 2000, Mario wrote:


> > What happens is that plctest runs with module name set to "TEST" by default, so
> > it doesn't have write permission on the point you are trying to write to.
> >

Don't worry I think I worked out what was wrong but someone may need to confirm my findings.

We changed the module name from ioserver to modbus_tcp. The program that demo started was called ioserver. (possible conflict). The [smm] points still had ioserver as their module reference. When I renamed all of these to modbus_tcp magic happened again.

Regards

Phil

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Philip Costigan:
> We changed the module name from ioserver to modbus_tcp. The program that
> demo started was called ioserver. (possible conflict). The [smm] points
> still had ioserver as their module reference.

Oops, I think that was my fault.

The program can be called anything, but the module name and the point owner in the [smm] section must match.

Sorry about that...

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

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