Something like LabView

J

Thread Starter

Jiri Baum

Curt Wuollet wrote on the Automation list:
> But something like Labview, sharing a map with an embedded PLC would be
> powerful medicine for a lot of solutions not served well by either alone.

What features would we want in such a language?

I've been toying with some ideas, but I haven't got around to actually doing anything more than that...


Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net

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

Curt Wuollet

Hi Jiri

I was thinking somewhat conceptually about the combination of procedural or even graphical programming means integrated with the cyclic solver to make a platform powerful for both logic and sequential tasking. Labview, as I understand it, is king in the test and measurement world because it makes it easy to acquire a dataset, eg. a waveform, and apply sophisticated processing to it without the knowlege to write a FFT, for example. You can display the results and do common waveform things, just about everything you would want to make measurements. It can also be used to sequence the application of signals, power supplies, etc. This is power a step beyond what we commonly think of as automation. As programmers, we like to build function libraries for anything we will be doing more than once. This is automating our programming, in a sense
as we now only have to make a function call. Then there's what people are
doing to add special functions to PLC's. A box with an input and output that can be treated like a special kind of relay. All these things get mixed together in my tortured mind and I think we could make a sort of higher level Automation Language that automates Automation. This is background for those that haven't been following my past ravings. The advantage that we have, building on a bigmips platform is that we have the power to run a very high level language and blow our critics away by being simpler than RLL and more powerful as well as attacking the glaring weaknesses of PLC's in communications and number crunching.

We have data acquisition facilities that make PLC analog inputs and outputs look pretty weak with microsecond acquisition times and deep buffers, in addition to logic at horrendous rates.

I can use that, you can use that, how do we make it so anyone can use it?

I think of things I do for integration like Open_Port tty1,19200,N81
instead of the boilerplate paragraph of rather dense C code that I use all the time. I manipulate a few bitmaps with pre defined constants and make some system calls and the deed is done. No reason that couldn't be automated to make comms as simple as RLL. A bevy of these like Open_Socket IP SN TCP/UDP, Open_File, etc. and then some simple things that operate on the fd's returned like: Send_String, Send_Array, Send_Regs, Log_it, yada, yada.
And some kind of help for protocols that works like expect. Send this, Expect that kind of dialogs. Some stuff for syncronization between programs and the PLC like: Wait_For I1, etc. and of course a full set of bit sets and clears and reads.

That kinda stuff for basics, I'm sure some of the PID and dsp stuff could be abstracted also. We could do the same stuff as labview without any real problem but I don't know if it would apply to our target audience. A lot of automation would quit working if you knew what the waveforme really looked like :^)

Look what a simplified language like, I hate to say it, "Visual Basic" does for making GUI programming accessable. I think we could gain a march on Big Automation if we can make an automation chainsaw that eliminates a lot of putzing around. The regular nature of the work suggests it is possible and the target audience is familiar with the concept and compromises.

Regards

cww


Jiri Baum wrote:
>
> Curt Wuollet wrote on the Automation list:
> > But something like Labview, sharing a map with an embedded PLC would be
> > powerful medicine for a lot of solutions not served well by either alone.
>
> What features would we want in such a language?
>
> I've been toying with some ideas, but I haven't got around to actually
> doing anything more than that...

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