Bob Page: > > If there is a hole in the offerings of your company and such companies > > as automationX, why not identify the specific hole(s) and promote > > development to fill those holes? Curt Wuollet: > I thought that was what I was doing. I was proposing simultanious > cooperating procedural and asynchronous logic processes The architecture supports this, no problem. > and a 4GL type language that would make that power accessable to folks > other than Linux systems programmers. The hard bit will be designing a language that we can all be proud of. Off the top of my head, we want the language to be elegant, accessible, powerful, scaleable. It needs to handle parallel actions and flow of time. In combination, a formidable problem - in solution, a formidable tool. To what extent should it be procedural? I don't know. There are other programming models that present themselves, but I don't know how about those, either. - A data-flow model would have the advantage that the parallelism would be built-in. It would be easy to explain using a production line metaphor, and easy to draw graphically on the screen. It could emulate procedural languages by passing along an empty datum (`token'). - Constraint programming, concentrating on the restrictions under which the machine operates, would have the advantage that it maps neatly to a great part of the automation problem. However, it is totally alien to most. Comments? All this, of course, is parallel to the ladder logic module. In PLC parlance, I guess it'd be called a coprocessor. Jiri -- Jiri Baum <[email protected]> Connect the power cable, interface cable and ground wire only in the methods indicated in the this manual. It may lead to fire. -- OKIPAGE 8z user's manual _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Sounds a lot like National Instruments "G". Too bad you can't target an 8086 with LabView... > Bob Page: > > > If there is a hole in the offerings of your company and such companies > > > as automationX, why not identify the specific hole(s) and promote > > > development to fill those holes? > > Curt Wuollet: > > I thought that was what I was doing. I was proposing simultanious > > cooperating procedural and asynchronous logic processes > > The architecture supports this, no problem. > > > and a 4GL type language that would make that power accessable to folks > > other than Linux systems programmers. > > The hard bit will be designing a language that we can all be proud of. > > Off the top of my head, we want the language to be elegant, accessible, > powerful, scaleable. It needs to handle parallel actions and flow of time. > In combination, a formidable problem - in solution, a formidable tool. > > To what extent should it be procedural? I don't know. There are other > programming models that present themselves, but I don't know how about > those, either. > > - A data-flow model would have the advantage that the parallelism would be > built-in. It would be easy to explain using a production line metaphor, > and easy to draw graphically on the screen. It could emulate procedural > languages by passing along an empty datum (`token'). > > - Constraint programming, concentrating on the restrictions under which the > machine operates, would have the advantage that it maps neatly to a great > part of the automation problem. However, it is totally alien to most. > > Comments? > > > All this, of course, is parallel to the ladder logic module. In PLC > parlance, I guess it'd be called a coprocessor. > > Jiri > -- > Jiri Baum <[email protected]> > Connect the power cable, interface cable and ground wire only in the > methods indicated in the this manual. It may lead to fire. > -- OKIPAGE 8z user's manual > > _______________________________________________ > LinuxPLC mailing list > [email protected] > http://linuxplc.org/mailman/listinfo/linuxplc >

 

Jiri Baum wrote: > Bob Page: > > > If there is a hole in the offerings of your company and such companies > > > as automationX, why not identify the specific hole(s) and promote > > > development to fill those holes? > > Curt Wuollet: > > I thought that was what I was doing. I was proposing simultanious > > cooperating procedural and asynchronous logic processes > > The architecture supports this, no problem. > > > and a 4GL type language that would make that power accessable to folks > > other than Linux systems programmers. > > The hard bit will be designing a language that we can all be proud of. And one that retains the advantages of a next generation language. Database 4GL's tend to be great for writing reports, less so for number crunching. I would suppose that an automation 4GL should be great at expressing processes and logic. More of another layer of abstraction than anything else, so you can write "send cmd_string to lathe", "wait for lathe ACK","send parm_string to lathe", etc. without the fiddly bits. And constructs like "wait until (label) = true then expression. In other words "natural language" for automation. > > > Off the top of my head, we want the language to be elegant, accessible, > powerful, scaleable. It needs to handle parallel actions and flow of time. > In combination, a formidable problem - in solution, a formidable tool. And then there's the interesting question of synchronizing parallel tasks and priorities. > > > To what extent should it be procedural? I don't know. There are other > programming models that present themselves, but I don't know how about > those, either. > > - A data-flow model would have the advantage that the parallelism would be > built-in. It would be easy to explain using a production line metaphor, > and easy to draw graphically on the screen. It could emulate procedural > languages by passing along an empty datum (`token'). > > - Constraint programming, concentrating on the restrictions under which the > machine operates, would have the advantage that it maps neatly to a great > part of the automation problem. However, it is totally alien to most. > > Comments? Whatever the model, we would want it to be appealing to use. Visual Basic is perhaps the worst possible choice for automation but people use it because they can "do stuff just like a programmer". > All this, of course, is parallel to the ladder logic module. In PLC > parlance, I guess it'd be called a coprocessor. Yes, one or the other or both. Perhaps synchronizing through the map? That would be a familiar easily understood method. Regards cww PS Good to hear from you Jiri. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

How about something like function blocks. It is already accepted by many people in the automation field. Juan Carlos Orozco ACElab Industrial Automation [email protected] www.ace-lab.com _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi Juan I expect this will be in addition to some sort of function blocks. Really, you need function blocks to get ladder to do things that aren't expressible in relays. I would see some of function library whose functions could be called from any of the programming languages. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

That's certainly one option; it's certainly accessible, and (if done neatly) it can be elegant. I'm not familiar with it enough to judge its scaleability and power (probably depends on the implementation, too).

Parallel actions are built-in (how are they synchronized?), but I'm not so sure about flow of time. Is there anything other than timer blocks that mimic old-fashioned timer relays?

Of all the things I can think of, time is one of the most difficult. Certainly we can ignore it and shove it onto the end-programmer, but that
doesn't appeal to me so.

Jiri
--
Jiri Baum <[email protected]>
"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
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi,

First of all, sorry for the duplicated "big demo" posting. (I was obviously not at my Linux machine

(read on)

Jiri Baum wrote:

> Jiri Baum:
> > > The hard bit will be designing a language that we can all be proud of.
> ...
> > > Off the top of my head, we want the language to be elegant,
accessible,
> > > powerful, scaleable. It needs to handle parallel actions and flow of
time.
> > > In combination, a formidable problem - in solution, a formidable tool.
>
> Juan Carlos Orozco:
> > How about something like function blocks. It is already accepted by many
> > people in the automation field.
>
> That's certainly one option; it's certainly accessible, and (if done
> neatly) it can be elegant. I'm not familiar with it enough to judge its
> scaleability and power (probably depends on the implementation, too).
>
> Parallel actions are built-in (how are they synchronized?), but I'm not so
> sure about flow of time. Is there anything other than timer blocks that
> mimic old-fashioned timer relays?
>

The synchronization for function blocks is basicaly the same that in ladder logic, they are just instructions that get executed periodically that result in a virtual parallel execution.

About your question of flow of time alternatives. Even though not related to function blocks, in the Siemens S7-22x there is a feature that emulates a state machine. It is implemented using ladder logic or instruction. In my experience this is a very powerful tool to program time sequences. There are state registers called S (not to confuse with SM) the instructions are
basically a start state block and end state block to delimit the instructions that are going to be processed if the state is active, there is also a transition instruction to activate a new state and deactivate the state where it originates. Using these comands one can build sequential
state machines with conditional transitions, split transitions or join transitions. Normally the time sequences are programmed using an ON-DELAY timers as trigers to the transitions. Also note that any number of states may be active at any given time, this gives the possibility of splitting the flow by making transitions to more than one state or the possibility to run several state machines concurrently. My way of using this is by generating a program block with the timing and state logic and a separate block where I
use the S variables to activate the actions (i.e. outputs). Without analyzing it in detail, this may be a subset of the petri nets. It may be
possible to adapt (or simply use) the linuxPLC petri nets to achieve a similar functionality. I am too lazy to check, do we have time functions in
the project yet (i.e. ON-DELAY, OFF-DELAY, ...). Or this is going to be exclusive of the IEC ladder logic implementation.

> Of all the things I can think of, time is one of the most difficult.
> Certainly we can ignore it and shove it onto the end-programmer, but that
> doesn't appeal to me so.

Also related to my previous state machine comments.

Juan Carlos Orozco

ACElab Industrial Automation
[email protected]
www.ace-lab.com

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