Having had to deal with about a half-dozen or so PLCs in a previous job (what a loooong time ago that was...), I'm not sure that modbus was the easiest ;-) That said, I've always toyed with a few designs that would get it working on platforms other than Windows (which is where I was at the time - job requirement, not personal choice ;-}). Anyway, my suggestions would be:

Package namespace: PLC::*. e.g., PLC::Modbus. Alternately, SCADA::Driver::PLC::* - depends on whether someone will want to do a full SCADA suite here or not ;-) I'd go with PLC::* first, and if someone wants to use SCADA::* later, they can have a driver that merely inherits from your PLC driver.

I'd also suggest, if you can, getting a hold of a second PLC with a different protocol. By looking at more than one protocol type, you may be able to better abstract what you're doing, making your objects a bit more higher-level. Think how bad DBI would have been if it were only designed for Oracle, for example.

So, what I'd want to get in here, in my ideal world that is ;-), would be methods that:

• Created any type of PLC::* object (e.g., PLC->new('driver:Modbus'))
• Registered memory points to request asyncronously - this way, your driver could optimise memory points that were close together into a single request of the PLC. Sure, you may be getting memory that you don't care about, but you'd reduce overall traffic by making fewer requests of the PLC.
• Requested a given memory point immediately. Opposite to the above is a synchronous request for a single data point. This should be documented as "try to avoid" as it will slow down most applications.
• Request for changed data. Each registered data point would be remembered (probably in a hash), but there'd be a separate hash or list or whatever to track data points that have changed. That way, the requestor could focus on only values that have changed. Each time this is called, you'd send back a list of tuples of the form ( [ $datapoint => $value ], ... ), not necessarily sorted, and then it would clear the changed hash. In a non-threaded model, this would also actually send out a single request on the line, wait for its response to return, parse it, etc.
• Set into threaded-model where the requests are sent out every $n seconds (where $n could be fractional - user-specified). This may be difficult to get going, so you may want to wait on it ;-)
• Request for a particular registered data point. If the data point isn't registered, this would be an error. If the data point just simply hasn't been requested yet, put that request to the front of the queue, and send the message (where you'd then potentially get more than a single data point back). Also clears that point from the "changed" list.
• "Peek" at data points/changed list. That is, get the values back, but don't clear the changed list.

Note: a lot of this will end up in the base PLC handler package. The actual driver only needs to be involved in determining the distance between two data points (in bytes or words or whatever it wants), what the maximum length of the request is allowed to be (modbus and modbus+ may have differing maximas, for example, and in the same unit as the distance), formulating the requests, sending them out (whether on a serial port or other method), and unpacking the reply. Pretty much the rest should be doable by the base PLC object - including any thread handling.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.