Today is...
Saturday, November 18, 2017
Welcome to the Modbus Community, about
the world's leading automation protocol.
Help?
I am in urgent need or raising a Square D PLC from the dead. ... may need to write drivers ... Can Linux be used?
By Mike Whiteley on 16 May, 2001 - 9:15 am

I am in urgent need or raising a Square D PLC from the dead.

It has the SY/MAX 400 processors and a SyMate Class 8010 TypeSFW374

No one knows anything about it (including me), but I have been charged with its resurrection. It has not worked been used in over 10 years.

The technology is somewhat foreign to me so I feel
underqualified to re-write new drivers and the current interface is a less than desirable DOS application.

Does this group assist in the use of Linux to talk with this beast?

I would like to use it to collect data and send it to an oracle database, then redistribute it out to JAVA applets served from an Apache server on the same box (as Oracle). This would be harder to do if I try to use the DOS app. It may run in win95, but I prefer to have it be reliable.

Any advice is greatly appreciated.

Mike

Michael Whiteley
Test Systems Engineering
Thiokol Propulsion
(435) 863-2561

By Curt Wuollet on 16 May, 2001 - 11:56 am

I can try to help, unfortunately I don't know much about SquareD stuff either. It's probably possible to reverse engineer the programming interface if it's serial as is typical for the time frame. You put a comm analyzer (datascope)between the DOS app and the PLC and note what happens when you do various things. The datascope can store the interchange and you write Linux code to send the same strings, etc. Then if the protocol isn't obvious you can twiddle bits until you understand what's going on. I can get you started with the framework to open a port and communicate. The datascope I use is DOS freeware. (I've been meaning to write a Linux version for years). Between this and some research you oughta be able to get it working. Perhaps if you were to detail what you know about the interface and exactly what you want to do, I can help and it would be instructive for those unfamiliar with Linux serial comms. We will probably have to do some of this down the road a bit. It's not too difficult once you get the hang of it.

Regards

cww

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mauricio Pupo on 21 May, 2001 - 9:17 am

I am very interested on this discussion, since I am working on something similar for my graduate project. I have used a comm analyzer to spy the serial communication with a commercial PLC and got the Modbus strings sent by the configurator for an AND function programmed in Ladder. The objective is to copy this string to Linux C code so that it will do the same for the PLC as the proprietary configuration software does. After that I plan to add a Web interface via CGI. Right now I am stuck in how to do the coding, as I lack proper C programming skills. So far, I have only experimented unsuccessfully with some Modbus RTU code from the cvs directory. Can someone advice me on how to start a C code in Linux for sending a Modbus RTU string to the PLC ?, say for example [01][3e][00][59][01][00][79][0c] (this is the start for downloading the AND function)
Thanks,
Mauricio S. Pupo


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 21 May, 2001 - 9:29 am

The LinuxPLC web site www.linuxplc.org has a links page which has a number of Modbus related sites.

For a simple introduction, may I suggest Paul McRae's Modbus Page.

Regards
Mark

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 21 May, 2001 - 9:30 am

Hi Mauricio

I'll be happy to send you the boilerplate I use to init a serial port and start sending data. For now, if you understand printf, sprintf is about the easiest way to format packets or strings to send. you simply declare an array, int buff[80} and sprintf lets you format the data in many different ways. e.g. sprintf(buff,"%h%h%h%h\0",a,b,c,d); Then, make sure the string is terminated with a null and use : write( fd, buff, sizeof(buff)); This is fairly automatic and lets you concentrate on the data.

I'm not sure whether Modbus RTU sends the ascii representation or the actual bytes represented by the hex notation in your example. If you can fill me in, I'll include code that should get you started. Linux serial facilities are truly excellent and great for automation projects.

Regards

cww


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jeff Thurman on 21 May, 2001 - 9:38 am

Curt:

Would you post this on the list. I have written modbus ascii and rtu in basic but not "c" and would be interested in seeing what your "boilerplate" is that you use to init a serial port.

jeff

By Curt Wuollet on 21 May, 2001 - 11:48 am

Hi Jeff,

No problem! It might be later on today or tonight as I've got some day job issues to deal with. In the meantime does anyone know just what actually hits the wire for Modbus RTU? I don't have anything handy that spells it out. I'm assuming from Jeff's mention of "ascii" and "rtu" that the bytes are binary. But, I have found the assuming anything in the weird world of
automation protocols is a bad idea. It only chenges the format string for sprintf but I'd like to get it right.

Regards

cww

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 21 May, 2001 - 1:30 pm

OK

Here's a small program I hacked together to demo a Matrix Orbital display with a keypad.

(program is an attachment to the following message: http://www.control.com/control_com/990552516/index_html)

Demonstrates setting up a port and reading and writing along with catching signals and restoring the port settings on exit. Please put on
your peril sensitive sunglasses and remember this was a hack. It does about everything you commonly need to do with a serial port. This is by the way an inexpensive way to do an operator interface unit :^). If anyone's interested I'll hunt down the Matrix Orbital PN.

Regards

cww

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Philip Costigan on 21 May, 2001 - 1:33 pm

On Tue, 22 May 2001 08:38, cww wrote:

> In the meantime does anyone know just what actually
> hits the wire for Modbus RTU? I don't have anything handy that spells it
> out.
>

In the reference guide it explains that RTU is basically raw byte data, It is sent with an address as a byte a function as a byte then a bunch of bytes for data followed by a 16 bit crc checksum. There is also a 3.5 character delay between transmissions so if the port falls asleep mid transmission then it is interpreted as end of transmission and an error will arise.

I hope this is what you are after.

--

Regards

Philip Costigan

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 21 May, 2001 - 1:40 pm

Thank you Phil.

This would mean that you simply replace the %h's in the sprintf with %c (char).
I put up some code and will help with questions. The timing issue is quite interesting,
perhaps retry on error ?. I have a crc algorithm around someplace as well.
I think.

Regards.

cww


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jiri Baum on 22 May, 2001 - 9:19 am

Curt Wuollet:
> I'm assuming from Jeff's mention of "ascii" and "rtu" that the bytes are
> binary.
...
> It only chenges the format string for sprintf but I'd like to get it
> right.

If you have a list of bytes, sprintf is an over-kill. Just do
buf[0] = byte1;
buf[1] = byte2;
buf[2] = byte3;
etc.

That way you can set each byte either as a number (42) or as a character ('*'), depending on what it is.


If it's a fixed-length packet, it's probably better to define a struct for it, anyway...

typedef struct {
char header[4];
char data[10];
char CRC[2];
} FooPacket;

(Probably better to avoid `int', though, on account of byte-order issues.)

Just pass that directly to write(2) and it'll do what you want.

Jiri
--
Jiri Baum <jiri@baum.com.au>
"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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 22 May, 2001 - 1:19 pm

Hi Jiri!
All quite true, but the first things most folks get familiar with in C is the
printf
family. Forgive my horrible hack. I do like your Mundie-ism. He's smarter than I thought. Substitute monopoly for "strong commercial software business model" and I think he's "got it".

Regards

cww

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jiri Baum on 22 May, 2001 - 1:30 pm

Curt Wuollet:
> All quite true, but the first things most folks get familiar with in C is
> the printf family.

I guess it doesn't matter either way; I guess my point was that there's no magic about binary - it just is in the computer and can continue to be in
there...

> Forgive my horrible hack.

No worries.

> I do like your Mundie-ism. He's smarter than I thought. Substitute
> monopoly for "strong commercial software business model" and I think he's
> "got it".

I think even without the substitution he's ``got it''... and he's bagging the GPL because he's on the ``strong commercial software business'' side.


Jiri
--
Jiri Baum <jiri@baum.com.au>
"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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Greg Goodman on 23 May, 2001 - 3:05 pm

> If it's a fixed-length packet, it's probably better to define a struct for
> it, anyway...
>
> typedef struct {
> char header[4];
> char data[10];
> char CRC[2];
> } FooPacket;

You have to be careful building structures to represent byte-streams. Depending on your platform, compiler, and compile-time options, the
compiler may pad a structure with extra bytes to force the structure's elements to align on a specific boundary. For example, a system that
requires structure elements to align on 4-byte boundaries would add two bytes of padding between FooPacket.data and FooPacket.CRC.

Something to beware of when writing code meant to be portable.

Greg Goodman
Chiron Consulting

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jiri Baum on 24 May, 2001 - 9:30 am

> > If it's a fixed-length packet, it's probably better to define a struct
> > for it, anyway...

> > typedef struct {
> > char header[4];
> > char data[10];
> > char CRC[2];
> > } FooPacket;

Greg Goodman:
> You have to be careful building structures to represent byte-streams.
> Depending on your platform, compiler, and compile-time options, the
> compiler may pad a structure with extra bytes to force the structure's
> elements to align on a specific boundary.

Yes, that's the other reason to avoid ints.

> For example, a system that requires structure elements to align on 4-byte
> boundaries would add two bytes of padding between FooPacket.data and
> FooPacket.CRC.

For a char[] ? What a weird platform that'd be...

For an int I wouldn't be surprised.


Jiri
--
Jiri Baum <jiri@baum.com.au>
"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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Andrew Kohlsmith on 24 May, 2001 - 9:35 am

> > For example, a system that requires structure elements to align on
4-byte
> > boundaries would add two bytes of padding between FooPacket.data and
> > FooPacket.CRC.

> For a char[] ? What a weird platform that'd be...
> For an int I wouldn't be surprised.

It's not expanding the char, it's making sure that the next variable is on a word/dword/qword boundary. You can make any compiler do it, or not do it with special #pragmas in relevant sections of your code or a global compiler
switch, although I'd suggest against the latter. Alignment of code and data makes things faster overall but when you're trying to make a very particular type of structure you should turn it off with a #pragma pack 0.

At least, that's how I remember #pragma pack. It's been a while. :-)

Regards,
Andrew

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 24 May, 2001 - 10:23 am

Gentlemen, please remember we're trying to help a beginner here. While I have always been intrigued by the subtleties of the GCC compiler
implementation, the reason I used the library functions I did was to avoid the esoteric and let the compiler deal with it. For Linux on an x86 for the moment. And using an array with a write that checks for length, while possibly not as space efficient as a struct, (although you'ld have to look at the machine code generated to be sure), let's you do things like printf and use the string functions avoiding overt pointer manipulation. After many years, I have found few instances where absolutely obvious code is improved by obfustication. Also Modbus packets are variable length and the simple code is reusable anyplace you have a file pointer. To do
Modbus/TCP you just open a socket and build your packet a little differently. And yes, there probably should be a few (unsigned char) in
there but it's readable and it works. I compiled and ran it before I sent it.

On a related note, my effort to become reacquainted with the code base has been delayed by rain in my computer room brought about by a week of foul weather. Fortunately, as a long time Linux fan I am well versed in tar and patches and after applying quantities to roof-0.2.1-17, I should be able to proceed. roof-0.2.1-18 seems to be working :^)

Regards

cww

PS For the uninitiated, I simply incremented the patch level. but we're nowhere near a release. Wife-1.0.0 has not interacted well, but will
provide me with diff output.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Andrew Kohlsmith on 24 May, 2001 - 10:33 am

> moment. And using an array with a write that checks for length, while
> possibly not as space efficient as a struct, (although you'ld have to look
> at the machine code generated to be sure), let's you do things like printf
> and use the string functions avoiding overt pointer manipulation. After

You most certainly cannot use the string functions with arrays containing ModBUS data. All string functions stop at a NULL and that NULL is way too common in ModBUS packet data.

I'm a big proponent of KISS -- the stupider your software, the less chance it has of biting you in the ass. But as Einstein said, "Things should be
made as simple as possible -- but no simpler." Using string functions for binary data is breaking this rule.

> many years, I have found few instances where absolutely obvious code
> is improved by obfustication. Also Modbus packets are variable length
> and the simple code is reusable anyplace you have a file pointer. To do
> Modbus/TCP you just open a socket and build your packet a little
> differently. And yes, there probably should be a few (unsigned char) in
> there but it's readable and it works. I compiled and ran it before I sent
it.

I agree with you that things should be simple (see above) -- At the same time though I must speak out when you claim that using structs and/or unions over array data is too complex. I can read all the data into a struct with a simple file pointer, just as you can. However my data is now structured; I can pull out the address or checksum or specific structured elements
without resorting to pointer arithmetic or clunky #DEFINEs. Avoiding arrays because of possible padding issues is silly. Everyone was a newbie at one time; how do you learn?

> On a related note, my effort to become reacquainted with the code base
> has been delayed by rain in my computer room brought about by a week
> of foul weather. Fortunately, as a long time Linux fan I am well versed in
> tar and patches and after applying quantities to roof-0.2.1-17, I should
be
> able to proceed. roof-0.2.1-18 seems to be working :^)

Ahh yes.. I have this problem as well on my garage. I had to apply the deshingle toolset and then use pry(1) to pull up the old tongue-and-groove roof boards to replace with chipboard. Unfortunately I threw out my back doing so and I have my roof temporarily functioning by use of the
undocumented tarp tool. :-) With a little luck I should be able to shingle in the next bit.

Regards,
Andrew

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 24 May, 2001 - 12:20 pm

Andrew Kohlsmith wrote:

> > moment. And using an array with a write that checks for length, while
> > possibly not as space efficient as a struct, (although you'ld have to look
> > at the machine code generated to be sure), let's you do things like printf
> > and use the string functions avoiding overt pointer manipulation. After
>
> You most certainly cannot use the string functions with arrays containing
> ModBUS data. All string functions stop at a NULL and that NULL is way too
> common in ModBUS packet data.

Agreed, the code I sent deals with ascii.

> I'm a big proponent of KISS -- the stupider your software, the less chance
> it has of biting you in the ass. But as Einstein said, "Things should be
> made as simple as possible -- but no simpler." Using string functions for
> binary data is breaking this rule.

Also agreed.

> > many years, I have found few instances where absolutely obvious code
> > is improved by obfustication. Also Modbus packets are variable length
> > and the simple code is reusable anyplace you have a file pointer. To do
> > Modbus/TCP you just open a socket and build your packet a little
> > differently. And yes, there probably should be a few (unsigned char) in
> > there but it's readable and it works. I compiled and ran it before I sent
> it.
>
> I agree with you that things should be simple (see above) -- At the same
> time though I must speak out when you claim that using structs and/or unions
> over array data is too complex. I can read all the data into a struct with
> a simple file pointer, just as you can. However my data is now structured;
> I can pull out the address or checksum or specific structured elements
> without resorting to pointer arithmetic or clunky #DEFINEs. Avoiding arrays
> because of possible padding issues is silly. Everyone was a newbie at one
> time; how do you learn?

I agree here too.. But, whose code is easier for a BASIC programmer to understand. And unions over array data, which declaring a struct on top of it would be, are much less than obvious. Everyone understands arrays and array ops. Of course it is
pointers under the covers and I often use both for convenience. The machine code generated is
probably identical. But the array ops are much more readable and understandable for someone coming from BASIC. For code that is to be shared, I try to make it obvious and I'm sufficiently secure that I don't mind being picked apart. I could rewrite the whole thing with pointers and even hex or binary constants to replace the silly defines in the header files but, I wouldn't be doing the person I wrote it for any favor. The reason I sent that particular hack is that I wrote it to show another programmer how to use the Matrix Orbital display and keypad. I am not a CS type, I write bonehead C because I have a lot of it around that I very infrequently look at and it helps me to be
able to jump back in quickly and easily. When I move on, it will help the poor soul who has to understand it immeasurably. Ten years ago, I used to write very terse code to fit in very small places with chunks of assembler to overcome speed issues. That is no longer necessary or in my view advisable unless profiling has shown a problem. I'm better now and have nothing to prove by outguessing the optimizer.

There is a larger issue here, we are writing code that is supposed to be useful to as many people as possible. If we want people to participate, the threshold should be as low as possible without sacrificing function. I find the code in the archive to be pretty tough sledding. I guess that makes me an idiot, but I have much more C
and Linux experience than the great majority of our target audience, the people we want to be able to use, study, and contribute to the code base. I doubt that too many people will want to dig into the core functionality we have so far but, as we move outward towards the user we have to make things a little more accessable or
having open source is of little consequence.

Regards

cww

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jiri Baum on 24 May, 2001 - 12:24 pm

Curt:
> > And using an array with a write that checks for length, while possibly
> > not as space efficient as a struct, (although you'ld have to look at
> > the machine code generated to be sure), let's you do things like printf
> > and use the string functions avoiding overt pointer manipulation.

Andrew Kohlsmith:
> You most certainly cannot use the string functions with arrays containing
> ModBUS data. All string functions stop at a NULL and that NULL is way
> too common in ModBUS packet data.

Agreed - definitely.

> But as Einstein said, "Things should be made as simple as possible -- but
> no simpler."

For simplest possible technique, I'd suggest using the buffer directly:

buf[0] = 42; /* first byte */
buf[1] = 86; /* second byte */
buf[2] = 99; /* third byte */

That's got to be simpler than sprintf(3)...


> At the same time though I must speak out when you claim that using
> structs and/or unions over array data is too complex.

Yup.

> I can read all the data into a struct with a simple file pointer, just as
> you can. However my data is now structured; I can pull out the address
> or checksum or specific structured elements

Exactly.

We should watch out for alignment problems, but I don't think I've ever seen gcc align a char. Byte-order is much more likely to bite us.

But do avoid the string functions, they'll do the wrong thing too often.

Jiri
--
Jiri Baum <jiri@baum.com.au>
"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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Peter Hopfgartner on 25 May, 2001 - 1:47 pm

My 2 cants: It really doesn't matter how the data is allocated in memory, keeping things in structs helps to keep your code readable. Simply provide your struct with "serialization", a read and a write function that generates univoquely a binary string from your struct and your struct from a binary string.

Peter

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jiri Baum on 25 May, 2001 - 2:07 pm

Sorry about the `me too' post, but I just wanted to put my name to that.
Peter seems to have made the most sense of us all.

Jiri
--
Jiri Baum <jiri@baum.com.au>
"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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Andrew Kohlsmith on 25 May, 2001 - 2:08 pm

I don't understand: arrays are already stored as serial data so why provide seperate routines that do nothing?

i.e.

typedef struct mystruct
{
char address;
int command;
char data[10];
char crc32;
};

*is* stored as a linear 15-byte array; it's just "organized" -- i.e. I can say mystruct.command instead of (int)data[1].

for read() and write() all you do is provide a pointer to the allocated structure. So long as the ocmpiler didn't decide to align your data you'll be fine (and how to prevent it from doing so has already been discussed). No "(de)serialization" functions are required.

If you want to access the data as a linear array, you can still do so.

i.e.
mystruct *data;

malloc(data, sizeof(struct mystruct));
read(fp, data, sizeof(struct mystruct));

mychecksum = (char *)data[14];
mychecksum = data->crc32;

Those last two lines are functionally equivalent but which is clearer to understand?

Anyway I never intended this to turn into a flame war. I just would prefer not to see the entire project littered with data[8], data[97], data[1], etc just because we want to protect the newbies from learning about arrays and pointers. They're very powerful constructs and if you haven't learned about them, dig in. Hell I was able to teach my brother about doubly linked lists in about an hour. Once past that initial hump it was all very clear. There's no point in keeping newbies newbies. And there's certainly no point
in DAMAGING the readability of code by not using arrays and pointers.

As Curt said (but I'm now paraphrasing and using against him): Open Source is a learning tool. If it's not readable it's useless.

Regards,
Andrew


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 25 May, 2001 - 2:32 pm

Well, first of all - no it is most probably not stored as 15 bytes.

It could take 14 bytes - if you have a 16 bit compiler and there is no aligning

It could take 15 bytes - if you have a 16 bit compiler and there is word align

It could take 16 bytes - if you have a 32 bit compiler and there is no aligning

It could take 17 bytes - if you have a 32 bit compiler and there is word align

It could take 21 bytes - if you have a 32 bit compiler and there is dword align

This is what I would expect and intel compiler to do, I would not bet that other compiler don't do it differently


First: never use int if you want to be sure of the size.

Second: as people here have said, there is the problem with aligning and it have to be taken into consideration if you want to store the entire struct in one operation. It would work, but be possibly less portable.

Third: the byte order would make this code behave
differently on different processor architectures.

File and communications formats should really be kept apart from how the information is stored in memory.

/Johan Bengtsson


Btw: you can not store a crc32 in a char, so I suggest either change the name to crc8 or to change the type to long or unsigned long.


Since everyone else have their side notes: does anyone of you know some site where _ can find some nice version of GirlFriend?


----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Andrew Kohlsmith on 25 May, 2001 - 3:25 pm

> Well, first of all - no it is most probably not stored
> as 15 bytes.

> Second: as people here have said, there is the problem
> with aligning and it have to be taken into consideration
> if you want to store the entire struct in one operation.
> It would work, but be possibly less portable.

Okay let's not get silly here; this is for Linux: that is automatically a 32 bit compiler (even uClinux uses a 32 bit compiler). When the 64 bit
compilers come out we'll discuss that then. But right now that point is moot. Also, I had already discussed alignment issues and how to get around them.

> Third: the byte order would make this code behave
> differently on different processor architectures.

Using arrays would not help this situation, but this point is also moot: the byte order is irrelavent because you must use what the network specifies, regardless of your processor's endianness. Take a look at the TCP/IP code for numerous examples.

> File and communications formats should really be kept
> apart from how the information is stored in memory.

Totally agreed, but how do straight linear arrays avoid any of these problems?

> Btw: you can not store a crc32 in a char, so I suggest
> either change the name to crc8 or to change the type to
> long or unsigned long.

You are of course correct here. A slip of the key on my part, so to speak.

Regards,
Andrew


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 29 May, 2001 - 9:10 am

Ok, I admit I got carried away by the example. I think everyone have got the point by now, if not before....

Sorry if I sounded too negative, that was not really my intent...


/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 25 May, 2001 - 2:35 pm

This is not a confrontation Andrew, I respect you guys and support you guys and I believe we have better programmers than most in the private sector. I normally wouldn't even rise to the bait, but I am going to, for my own masochistic satisfaction, approach the whole project as a newbie and try to raise questions and communicate observations. The extent to which we can make that experience survivable will determine, in large part, how many people will actually join in our effort.

My only point is that we are not aiming this at universities. My goal is to get more people working on this. I assume we are speaking to the larger issue as that hack is not part of the project. For what it's worth, I still don't regret trying to help the guy. We haven't got any more questions, why do you think
that might be?
We need more programmers. If I am not qualified to contribute, I suspect the pool of potential developers is unworkably small. We are having a real problem with getting people over the hump from wanting to contribute to actually writing code. This is one of the barriers. I'm all ears for your suggestions on how to solve that problem. You won't be able to discourage me because I put myself in the position of being scorched by posting my code and I am the advocate for all the people who wanted to be involved and decided not to. If I had contributed that code, would I do it again? Not very likely. While I am
still very opinionated and very idealistic, I have put much of that aside for the good of the project. I would be extremely happy if we could get to the point where you have aspiring programmers to educate. Me, I'm incorrigable :^)
Help me get talent on board.

Regards

cww

PS I may not be much of a programmer, but I do have a lot of Linux automation code running in production as we speak.


______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Andrew Kohlsmith on 25 May, 2001 - 3:58 pm

> This is not a confrontation Andrew, I respect you guys and support you
guys
> and I believe we have better programmers than most in the private sector.
> I normally wouldn't even rise to the bait, but I am going to, for my own
> masochistic satisfaction, approach the whole project as a newbie and try
> to raise questions and communicate observations. The extent to which we
> can make that experience survivable will determine, in large part, how
many
> people will actually join in our effort.

I completely understand the need for more fingers at the keyboard. The question, however, is do we want good code or code that newbies can
understand? Before you hit ^R, read on...

Now my belief is that *both* can be satisfied. Arrays and pointers do NOT get tricky until you really start doing goofy things with them. And if a newbie wants to contribute that is a WONDERFUL thing! But dumbifying the code to the point where anyone who is 10 days into their "Learn C in 21 Days" book can contribute just so they can code is insane in my opinion.
The project will suffer and will become unreadable / unmaintainable. Structure is important!

If they have trouble grasping a concept, let them ask! I regularly have to ask questions of the senior engineers here because I simply don't know. But instead of reducing the project to something that anyone could work on they instead explain the one hitch or two that I couldn't get past and now not only am I smarter for asking, but the project doesn't suffer. (... and in a
couple weeks I'm on another hitch but that's what the process is all about.)

I didn't mean for my initial comment to turn into this big flame out. In fact I think this may be my last post on this matter. All I am humbly
suggesting is that the "cut off" point for programmers be someone with at least basic knowledge of C. Arrays, in my opinion, are basic knowledge of C. Advanced pointer arithmetic? Surely not. We're not asking for doubly-linked lists or balanced trees though; I'm just asking that we don't do everything in linear char arrays. It's the old hammer / nail saying.

> My only point is that we are not aiming this at universities. My goal is
to get
> more people working on this. I assume we are speaking to the larger issue
as
> that hack is not part of the project. For what it's worth, I still don't
regret
> trying to help the guy. We haven't got any more questions, why do you
think
> that might be?

Agreed. Totally agreed. I'm not asking that we use the latest and greatest coding techniques and algorithms. (Hell I don't agree with some of them
either but I digress.) There's no need for that. There's no need to hand-code in assembly. There's no need for this arguement. (? This is a
pretty calm arguement, heh) I am not condemning you for helping anybody!

> We need more programmers. If I am not qualified to contribute, I suspect
> the pool of potential developers is unworkably small. We are having a real
> problem with getting people over the hump from wanting to contribute to
actually
> writing code. This is one of the barriers. I'm all ears for your
suggestions on
> how to solve that problem. You won't be able to discourage me because I
put
> myself in the position of being scorched by posting my code and I am the
> advocate for all the people who wanted to be involved and decided not to.

I think part of this problem is that there is a large number of people who can do ladder logic and the higher level stuff waiting to use LinuxPLC but don't have the lowlevel know-how in order to help it to that point. I would FAR rather bring these people up to speed on certain aspects of C programming than I would bring the whole project to their current level of
comprehension of the C language. It might take a bit longer but the code base will be far better for it.

> If I had contributed that code, would I do it again? Not very likely.
While I am
> still very opinionated and very idealistic, I have put much of that aside
for
> the good of the project. I would be extremely happy if we could get to
the point
> where you have aspiring programmers to educate. Me, I'm incorrigable :^)
> Help me get talent on board.

As far as educating new programmers: I never said that's what I wanted to do: I'm just a grizzled old embedded C/asm programmer with too much time at my day job to read LinuxPLC. :-) I would certainly help anyone who asked though.

Now if I were someone new to something and I knew that I didn't know everything, I would *expect* criticism on my contributed code. Would I
stop? If it became overwhelming, maybe. But I don't remember blasting anyone; I do remember backing up someone else's comment on how arrays are better suited to a specific type of problem.

Take uClinux for example: I *am* a newbie in this area. Kernel programming is challenging as hell, even when you have multiple architectures to go from. How am I learning it? I'm "forward-porting" uClinux-2.4 to the MCF5206 processor. The old 2.0.36 source worked beautifully on this
processor but there are a LOT of lowlevel changes between 2.0 and 2.4 and I've decided that the best way to learn lowlevel kernel programming is to forward port this.

Do I assume that what I'm doing is being done right? Hell no, I have asked countless questions, tinkered with endless bits of code and hit that damn reset button far more than I have wanted to. Do I get discouraged? Sometimes; I usually can only work on this kind of stuff at the end of the day and after the kids are in bed. So I'm already tired and a little grumpy. :-) But in the same vein I don't expect the uClinux kernel hackers to say "That's alright, we'll let your newbie code into the core
anyway" -- I expect them to help bring me up to their level so that my code can stand alongside theirs and be as robust and *right* as possible. That means unlearning some things and relearning the right way to do things.

It's the same in this area (at least from my point of view) -- I am *personally* very happy that there are people who don't have all the
knowledge but yet want to take a crack at getting their name in the credits. To me, however, they must get themselves up to speed so that their code
meets certain standards I've come to like in the software industry. Getting up to speed involves hacking out code, putting it up for display and hearing people call bits and pieces ugly and other pieces art. It involves criticism and encouragement and trial and error and lots and lots of compiler time. Now I fully realize that I'm not the project lead and therefore my standards don't have much pull, but in an open mailing list I will certainly try and encourage them to do things the right way -- the
professional way -- so that they learn correctly instead of thinking that they do know it all. In effect I'll try and indoctrinate my standards on
others. This in iself gathers a lot of criticism (of my standards) and I often find that I'll end up raising them even higher because I learn new
things. Is this a bad thing?

I am very much a "throw me in the lake to learn to swim" kind of person; that's how I seem to pick up new ideas and technologies best. I suppose what you're seeing in my postings to the list is that type of mentality. "Get some code out there and be prepared to take notes on how to make it better." or, more broadly, "You have the opportunity to fail."

> PS I may not be much of a programmer, but I do have a lot of Linux
automation
> code running in production as we speak

I've never questioned your abilities as a programmer. Code which works is better than elegant code which doesn't, but should we not all strive for excellence?

Anyway I've already written too much. I hope that this clears up my standpoint on this (and I guess in life in general) and helps to AVERT some
flamage.

Regards,
Andrew

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 26 May, 2001 - 11:41 am

Andrew Kohlsmith wrote:
>
> > This is not a confrontation Andrew, I respect you guys and support you
> guys
> > and I believe we have better programmers than most in the private sector.
> > I normally wouldn't even rise to the bait, but I am going to, for my own
> > masochistic satisfaction, approach the whole project as a newbie and try
> > to raise questions and communicate observations. The extent to which we
> > can make that experience survivable will determine, in large part, how
> many
> > people will actually join in our effort.
>
> I completely understand the need for more fingers at the keyboard. The
> question, however, is do we want good code or code that newbies can
> understand?

***YES***

Before you hit ^R, read on...

I did.


>
> Now my belief is that *both* can be satisfied. Arrays and pointers do NOT
> get tricky until you really start doing goofy things with them. And if a
> newbie wants to contribute that is a WONDERFUL thing! But dumbifying the
> code to the point where anyone who is 10 days into their "Learn C in 21
> Days" book can contribute just so they can code is insane in my opinion.
> The project will suffer and will become unreadable / unmaintainable.
> Structure is important!

For code, or building a cathedral?

>
> If they have trouble grasping a concept, let them ask! I regularly have to
> ask questions of the senior engineers here because I simply don't know. But
> instead of reducing the project to something that anyone could work on they
> instead explain the one hitch or two that I couldn't get past and now not
> only am I smarter for asking, but the project doesn't suffer. (... and in a
> couple weeks I'm on another hitch but that's what the process is all about.)

Most volunteers won't ask, especially if their hair is singed, they just go away.

> I didn't mean for my initial comment to turn into this big flame out. In
> fact I think this may be my last post on this matter. All I am humbly
> suggesting is that the "cut off" point for programmers be someone with at
> least basic knowledge of C. Arrays, in my opinion, are basic knowledge of
> C. Advanced pointer arithmetic? Surely not. We're not asking for
> doubly-linked lists or balanced trees though; I'm just asking that we don't
> do everything in linear char arrays. It's the old hammer / nail saying.
>

Right now, I'd take a ladder editor if it was written in BASIC.

> > My only point is that we are not aiming this at universities. My goal is
> to get
> > more people working on this. I assume we are speaking to the larger issue
> as
> > that hack is not part of the project. For what it's worth, I still don't
> regret
> > trying to help the guy. We haven't got any more questions, why do you
> think
> > that might be?
>
> Agreed. Totally agreed. I'm not asking that we use the latest and greatest
> coding techniques and algorithms. (Hell I don't agree with some of them
> either but I digress.) There's no need for that. There's no need to
> hand-code in assembly. There's no need for this arguement. (? This is a
> pretty calm arguement, heh) I am not condemning you for helping anybody!

You'll know when I'm arguing with you. This is a discussion, and an important one.

> > We need more programmers. If I am not qualified to contribute, I suspect
> > the pool of potential developers is unworkably small. We are having a real
> > problem with getting people over the hump from wanting to contribute to
> actually
> > writing code. This is one of the barriers. I'm all ears for your
> suggestions on
> > how to solve that problem. You won't be able to discourage me because I
> put
> > myself in the position of being scorched by posting my code and I am the
> > advocate for all the people who wanted to be involved and decided not to.
>
> I think part of this problem is that there is a large number of people who
> can do ladder logic and the higher level stuff waiting to use LinuxPLC but
> don't have the lowlevel know-how in order to help it to that point. I would
> FAR rather bring these people up to speed on certain aspects of C
> programming than I would bring the whole project to their current level of
> comprehension of the C language. It might take a bit longer but the code
> base will be far better for it.

And I would rather see a reasonable compromise or more importantly, consideration going forward.

> > If I had contributed that code, would I do it again? Not very likely.
> While I am
> > still very opinionated and very idealistic, I have put much of that aside
> for
> > the good of the project. I would be extremely happy if we could get to
> the point
> > where you have aspiring programmers to educate. Me, I'm incorrigable :^)
> > Help me get talent on board.
>
> As far as educating new programmers: I never said that's what I wanted to
> do: I'm just a grizzled old embedded C/asm programmer with too much time at
> my day job to read LinuxPLC. :-) I would certainly help anyone who asked
> though.

Great, you have a skill set that we could really use! What can I mark you down for?

> Now if I were someone new to something and I knew that I didn't know
> everything, I would *expect* criticism on my contributed code. Would I
> stop? If it became overwhelming, maybe. But I don't remember blasting
> anyone; I do remember backing up someone else's comment on how arrays are
> better suited to a specific type of problem.
>
> Take uClinux for example: I *am* a newbie in this area. Kernel programming
> is challenging as hell, even when you have multiple architectures to go
> from. How am I learning it? I'm "forward-porting" uClinux-2.4 to the
> MCF5206 processor. The old 2.0.36 source worked beautifully on this
> processor but there are a LOT of lowlevel changes between 2.0 and 2.4 and
> I've decided that the best way to learn lowlevel kernel programming is to
> forward port this.
>
> Do I assume that what I'm doing is being done right? Hell no, I have asked
> countless questions, tinkered with endless bits of code and hit that damn
> reset button far more than I have wanted to. Do I get discouraged?
> Sometimes; I usually can only work on this kind of stuff at the end of the
> day and after the kids are in bed. So I'm already tired and a little
> grumpy. :-) But in the same vein I don't expect the uClinux kernel
> hackers to say "That's alright, we'll let your newbie code into the core
> anyway" -- I expect them to help bring me up to their level so that my code
> can stand alongside theirs and be as robust and *right* as possible. That
> means unlearning some things and relearning the right way to do things.
>
> It's the same in this area (at least from my point of view) -- I am
> *personally* very happy that there are people who don't have all the
> knowledge but yet want to take a crack at getting their name in the credits.
> To me, however, they must get themselves up to speed so that their code
> meets certain standards I've come to like in the software industry. Getting
> up to speed involves hacking out code, putting it up for display and hearing
> people call bits and pieces ugly and other pieces art. It involves
> criticism and encouragement and trial and error and lots and lots of
> compiler time. Now I fully realize that I'm not the project lead and
> therefore my standards don't have much pull, but in an open mailing list I
> will certainly try and encourage them to do things the right way -- the
> professional way -- so that they learn correctly instead of thinking that
> they do know it all. In effect I'll try and indoctrinate my standards on
> others. This in iself gathers a lot of criticism (of my standards) and I
> often find that I'll end up raising them even higher because I learn new
> things. Is this a bad thing?
>
> I am very much a "throw me in the lake to learn to swim" kind of person;
> that's how I seem to pick up new ideas and technologies best. I suppose
> what you're seeing in my postings to the list is that type of mentality.
> "Get some code out there and be prepared to take notes on how to make it
> better." or, more broadly, "You have the opportunity to fail."
>
> > PS I may not be much of a programmer, but I do have a lot of Linux automation
> > code running in production as we speak
>
> I've never questioned your abilities as a programmer. Code which works is
> better than elegant code which doesn't, but should we not all strive for
> excellence?
>
> Anyway I've already written too much. I hope that this clears up my
> standpoint on this (and I guess in life in general) and helps to AVERT some
> flamage.
>
> Regards,
> Andrew

Don't think that I don't appreciate your viewpoint or that I'll even remember this next time we communicate. I simply am trying to deal with a less than ideal world and need more workable solutions than theory. My personal views on coding are secondary to what the project needs.

Peace,

cww
>
> _______________________________________________
> LinuxPLC mailing list
> LinuxPLC@linuxplc.org
> http://linuxplc.org/mailman/listinfo/linuxplc

By Andrew Kohlsmith on 27 May, 2001 - 1:01 pm

> > The project will suffer and will become unreadable / unmaintainable.
> > Structure is important!
> For code, or building a cathedral?

Both, actually. I've seen far too many experienced programmers driven by poor management and end up with disgustingly unmaintainable code.

[aside -- have you ever seen spaghetti C++ code? I didn't think it was possible until I had to clean it up.]

> Most volunteers won't ask, especially if their hair is singed, they just
> go away.

Hmmm... It sounds like they wouldn't have the gumption to be a maintaner anyway. It sounds pretty cynical but if they're gonna drop off like a bride's nightie their help won't be any help at all.

> Right now, I'd take a ladder editor if it was written in BASIC.

Noted.

> > don't have the lowlevel know-how in order to help it to that point. I
would
> > FAR rather bring these people up to speed on certain aspects of C
> > programming than I would bring the whole project to their current level
of
> > comprehension of the C language. It might take a bit longer but the
code
> > base will be far better for it.

> And I would rather see a reasonable compromise or more importantly,
> consideration going forward.

"consideration going forward" -- I don't understand this term...

You're right; there will have to be some compromise; And as people get up to speed and learn the what-to-do and what-not-to-dos, parts of the code will be rewritten and made "more better" as the project matures.

My comments about structure and ideals were more about what the "coding style" should be like, rather than a criticism on any individual module or alpha code. There is always room for improvement; I was just trying to say that "first run" or "functional prototype" code shouldn't be accepted as golden when obvious or newbie (from a fluent C standpoint) mistakes / techniques were used.

I'm not trying to stave off development. I'm just trying to prevent mediocre from being the norm.

> Great, you have a skill set that we could really use! What can I mark
> you down for?

As soon as I get some of my contract work off my plate I'd love to take a crack at the ladder logic entry. I'm not particularly good at UI (embedded means never having to make it human-pretty <g>) but I think I could do something which would work quite nicely.

Seeing as how you need that *now* though, I don't want to leave you in a lurch. Is there a list of what's needed somewhere?

> Don't think that I don't appreciate your viewpoint or that I'll even
> remember this next time we communicate. I simply am trying to deal with
> a less than ideal world and need more workable solutions than theory.
> My personal views on coding are secondary to what the project needs.

As stated in my previous paragraph: do you have a list of what's needed (however lengthy it may be at this point)? I briefly visited the linuxplc.org website and it looks like you have a lot of the base functionality laid out and have a clear direction for where you want to go with the project. That's more than a lot of projects have. Remember that just because it isn't progressing at Internet Time doesn't mean that it's all bad. :-)

Regards,
Andrew


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 29 May, 2001 - 9:50 am

We need programming and configuration tools, drivers, a generalized HMI, languages, flash memory facilities, whatever you want to do we can
accommodate you. In the meantime, spread the word in your circles that we could use C programmers and people with flex and bison experience. If
all our lurkers could just do that, we'll raise the body count.

Regards

cww

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 26 May, 2001 - 1:03 pm

We need programming and configuration tools, drivers, a generalized HMI, languages, flash memory facilities, whatever you want to do we can
accommodate you. In the meantime, spread the word in your circles that we could use C programmers and people with flex and bison experience. If all
our lurkers could just do that, we'll raise the body count.

Regards

cww


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Tony Robohn on 16 May, 2001 - 3:27 pm

I replied to your post under Applications, this post has a little more info. The SFW374 is the programming software (the older version). If you want to collect data out of this PLC, your best bet may be one of the Niobrara (www.niobrara.com) cards that will let you communicate with the PLC with Modbus. Once the information is available via Modbus, you can use Java to communicate. I remember seeing some Modbus Java classes that someone developed available on the internet. A search with any search engine should locate them.

Hope this helps,

Tony

By Mark Hutton on 17 May, 2001 - 8:27 am

There are SquareD drivers for Linux at the Linux Lab project.

The URL is on the Links page on www.linuxplc.org

I hope this is of use.

Regards
Mark Hutton

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Woudenberg on 21 July, 2001 - 2:21 am

The documentation for the Synet communication is still available round hear if your interested.

Mike,

To reuse the Sq d sy-max you will need the sfw374 program and a security key (dongle). You will also need a sq d interface to hook from your computer to channel 1 on the processor. I maintain 6 of these beast at my place of emoloyment every day. Feel free to email me if you have questions.

Don