Hi all;

It seems an opportune time during this brief respite from reading mail to report progress on the Opto22 ENET code. I have code that reads and
writes all points, the mode that we would use in a scanning situation. This has enabled me to test the rack a little. I have an issue or two for the Opto folks but it does actually work. The major difficulty was their encoding which wasn't obvious (to me) but should be easy enough to translate. I am trying to find a way to leave the connection up rather than open and close all the time, but the hardware does odd things when I string a few operations together. In the spec, it does say that the sequence is: connect, configure, command, close. When I toggle the outputs say 100 times, I have to insert usleeps between the closes and opens. Not much time, 100 usec. will do. Also, I get a seconds worth of writes, (about 30) and then things stop for a second. It alternates this way until the loop completes. A private network and 100baseT switch didn't change things so Monday I'll talk to Opto and get their opinion. It gives me something to do while I'm waiting to find out how the IO subsystem is going to work :^).

Regards

Curt W.

WOT

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

 

> -----Original Message-----
> From: Curt Wuollet [mailto:[email protected]]
> Sent: Saturday, February 05, 2000 12:56 PM
>
> It seems an opportune time during this brief respite from reading mail
> to report progress on the Opto22 ENET code. I have code that reads and
> writes all points, the mode that we would use in a scanning situation.
> This has enabled me to test the rack a little. I have an issue or two
> for the Opto folks but it does actually work. The major difficulty was
> their encoding which wasn't obvious (to me) but should be easy enough
> to translate. I am trying to find a way to leave the connection up
> rather than open and close all the time, but the hardware does odd
> things when I string a few operations together. In the spec, it does
> say that the sequence is: connect, configure, command, close. When I
> toggle the outputs say 100 times, I have to insert usleeps between
> the closes and opens.

By "connect/close" I assume you mean open/close a socket?

Make sure your TCP params are "optimum", whatever that means. Some systems have built-in delays (like Windoz) before a specific port can be reopened. Closing your socket in different manners may affect this.

> Not much time, 100 usec. will do. Also, I get
> a seconds worth of writes, (about 30) and then things stop
> for a second.

This you may have to ask them, but my guess is that the Opto22 tool doesn't expect you to close the socket so often. Most HMI would just open a socket, "connect", and loop & talk without closing for days/years.

The Modbus/TCP spec (for reasons I don't agree with) suggests the rapid open/close method, but my Modbus/TCP units don't do that. I'd say better to put a timer in your driver, if there is no activity for say 5 seconds, then close the Modbus/TCP socket otherwise leave it over.

You could be forcing some kind of "garbage collection" in the Opto22 where it is going thru and cleaning up some cache of available socket resources. Keep in mind the Opto isn't running a big OS like Linux and the user probably "hardcoded" the socket management - I have to do that in my "thin servers".

There may also be some form of "round-robin" delay in the Opto22 recognizing you have closed a socket. Again, that is how my hardcoded thin servers would have to do it.

Regards

Lynn August Linse, Senior Product Application Engineer
15353 Barranca Parkway, Lantronix Inc, Irvine CA 92618
[email protected] www.lantronix.com
Tel: (949)450-7272 Fax: (949)453-7132


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