Re^3: Perl::Minimal -- the good, bad, and the ugly...

One of the items I would be particularly interested in is an OPC module for PLC's. Almost all factory floor automation is run on PLC's, the development environments for which are written by MS Platinum Partners, and generally is buggy, slow, and costly to keep updated(licensing is outrageous from my perspective). Some of the big names are GE and Rockwell, though there are many more.

I attended an conference/trade show in Chicago last year where a company had developed a 'card' which natively talked to both the PLC and an MSSQL DB, acting as a direct link between the manufacturing equipment/cell and the database. This is unique in that under normal circumstances, data is collected by the PLC and sent via some communication channel(there are many) to an OPC server which then stores the data, and may push that data on to a DB or a DB may 'query' the OPC service where the data is stored. This middle-ware adds latency and bandwidth overhead where it is not needed.

Generally, PLC are for, and very good at, machine control. They are really not designed for applying/supplying business logic. Just machine control. Never-the-less, data from machine control is often good for and used for much more than just making sure the given machine operates properly and safely. It is in fact useful for Data Driven Decision making at the business level.

With that short description out of the way: Those 'cards' that plug into a PLC are just embedded systems that bypass the middle-ware, thus reducing the latency issues, and much of the bandwidth as well. There is no reason those embedded system need to be running proprietary software. And Perl would bring an enormous amount of flexibility(not to mention cost reduction) to the table in this regard.

This is just one more example of the potential usefulness of your concept of minimal Core Perl's. OPC is actually and open standard which means Perl modules could be developed for this purpose. Being able to break away from the M$ paradigm on the mfg. floor would be, in my view, very attractive.

There have been some other folks here at PM that have used OPC and Perl...( Like here)

...the majority is always wrong, and always the last to know about it...

Insanity: Doing the same thing over and over again and expecting different results...

A solution is nothing more than a clearly stated problem...otherwise, the problem is not a problem, it is a facct

wjw

Comment on Re^3: Perl::Minimal -- the good, bad, and the ugly...

Replies are listed 'Best First'.
Re^4: Perl::Minimal -- the good, bad, and the ugly... by taint (Chaplain) on Jun 02, 2014 at 02:33 UTC
Indeed, wjw. I had envisioned many possibilities, over the years. But yours is one that never occurred to me. In spite of the fact I have spent several years working with CNC -- both for metal, and for wood manufacturing. While, in those cases, the cards merely contain routines, which can be re-written, or changed at any time. The one you're introducing seems quite interesting, and seemingly, far more complex. And indeed, could be an ideal application for a Minimal Perl. ++ for bringing it up. :) I'm all in for this (Minimal Perl), and am more than willing to make the commitment. There's just too many reasons/applications, to overlook it's usefulness. At this point, for me. It comes down to the "mechanics" of it all. Both to providing Public Resources, and, more importantly, figuring out the best way to accomplish the "actual creation". As to "public resources"; some sort of RCS, VCS will/should be created. But with the myriad of possibilities available. Exactly which will perhaps require some time, and feedback to best determine -- a consensus, from anyone wishing to be involved. I have the resources, to provide for any one of them. I'd also be interested in suggestions, and or pointers, for the best approach to actually create this "Minimal Perl". There seems to be so many possible directions to take. I'd really feel more comfortable hearing from others, before investing much time in a direction, that was not the best choice. :) Thanks for pointing out another great potential use for Minimal Perl, wjw. --Chris Ąλɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH	[reply]

Replies are listed 'Best First'.

Re^4: Perl::Minimal -- the good, bad, and the ugly...
by taint (Chaplain) on Jun 02, 2014 at 02:33 UTC

wjw

I had envisioned many possibilities, over the years. But yours is one that never occurred to me. In spite of the fact I have spent several years working with CNC -- both for metal, and for wood manufacturing. While, in those cases, the cards merely contain routines, which can be re-written, or changed at any time. The one you're introducing seems quite interesting, and seemingly, far more complex. And indeed, could be an ideal application for a Minimal Perl. ++ for bringing it up. :)

I'm all in for this (Minimal Perl), and am more than willing to make the commitment. There's just too many reasons/applications, to overlook it's usefulness.

At this point, for me. It comes down to the "mechanics" of it all. Both to providing Public Resources, and, more importantly, figuring out the best way to accomplish the "actual creation". As to "public resources"; some sort of RCS, VCS will/should be created. But with the myriad of possibilities available. Exactly which will perhaps require some time, and feedback to best determine -- a consensus, from anyone wishing to be involved. I have the resources, to provide for any one of them. I'd also be interested in suggestions, and or pointers, for the best approach to actually create this "Minimal Perl". There seems to be so many possible directions to take. I'd really feel more comfortable hearing from others, before investing much time in a direction, that was not the best choice. :)

Thanks for pointing out another great potential use for Minimal Perl, wjw.

--Chris

Ąλɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

[reply]