On February 24, 2004, Michael Griffin wrote:
<clip>
> If the project involved some back and forth, that is changing the drawing
> after the PLC program was started, then the information would need to flow
> both ways. <

This is most likely, I suspect

In any case, it covers both of the other two possibilities, so it'd be best to design for this.

> If the PLC software had
> the device data available to it, it could tell you not just the symbol
> name, but also what is actually connected to it - which would be an aid to
> troubleshooting. <

Indeed. The circuit drawing might also be (somewhat) animated, so that the computer would tell you what voltages should be on which wires, in the same way that it does for ladder rungs. (That'd let you troubleshoot by
reconciling between what the computer thinks and what the voltmeter says.)

> The XML file seems like the obvious and simple choice, but may have
> limitations for large projects involving multiple people. The problem would
> be in keeping the different versions in sync if more than one person can
> edit them. <

Well, that's the existing version-control problem of multiple people editing the PLC program or multiple people editing a CAD drawing. It'd be made somewhat worse by involving several departments, but it's already cross department due to maintenance...

Any of the existing version-control technologies would do the trick; but you do have to keep it in mind while designing the software.

> Another means might be to have a third application which is used for
> creating and editting symbol files, from which both the CAD and PLC
> programs import their data. <

Ideally you want a two-way connection, so that in your CAD or PLC software you can invoke the "add a symbol" function and pull up the "symbol properties" dialog.

> perhaps even pulling design
> information from the mechanical drawings. <

Now that'd be really neat

As a pipe dream, this would note the location of motors and limit switches and automatically generate associations between them in the PLC programming software (including diagnostic messages when the motor should've reached the
limit switch by now, but hasn't - just fill in the timeout).

Anyway, that's well in the future (many years). For now, just displaying all the related drawings to the maintenance tech would do.

Another many-years-hence possibility would be the reverse: using the PLC program to animate the mechanical drawings.

> Some or even all of the above may not be entirely new. It does seem rather
> obvious to anyone who has worked in this field. I have seen products which
> do pieces of it. I haven't however actually seen anything which does all of
> this. I suspect that the reason for this is the lack of open standard data
> formats which would enable the exchange of data between software written by
> different parties. <

Well, the obvious solution is to use open-source software: you can read (and reuse) the code which reads and writes their formats, write the bit in the middle that manages it all, and even submit patches to them to integrate it into their respective menus.

Can we look forward to you announcing this project soon?

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 

On February 26, 2004, Jiri Baum wrote:
<clip>
> Indeed. The circuit drawing might also be (somewhat) animated, so that the
> computer would tell you what voltages should be on which wires, in the same
> way that it does for ladder rungs. (That'd let you troubleshoot by
> reconciling between what the computer thinks and what the voltmeter says.)
<clip>

This would work only for fairly simple circuits, otherwise you would have to model the whole machine. This might be more trouble than the end result is worth. My original thought was that it would give you a device information
(e.g. brand, model number, rating, etc.) so that you could have some basic identifying information available without having to look up the electrical schematics and bill of material. For example, it could give you an idea of what kind of device you are actually turning on when you "enable feeder 1". This would be a "nice" feature that is really just making use of information that would already be in the symbol definition list.

> > The XML file seems like the obvious and simple choice, but may have
> > limitations for large projects involving multiple people. The problem
> > would be in keeping the different versions in sync if more than one
> > person can edit them. <
>
> Well, that's the existing version-control problem of multiple people
> editing the PLC program or multiple people editing a CAD drawing.
<clip>
> Any of the existing version-control technologies would do the trick; but
> you do have to keep it in mind while designing the software. <

If everyone was connected by the same network, a conventional document management system might work as well. This is similar to version control software for code, but CAD people are already used to the terminology of document management for drawings.

If you had to allow simultaneous editing (especially at widely separated sites without real time network connections) then you would want some sort of document merge facility to reconcile two changed versions. This is possibly analogous to merging code trees in a distributed software project.

> > Another means might be to have a third application which is used for
> > creating and editting symbol files, from which both the CAD and PLC
> > programs import their data. <
>
> Ideally you want a two-way connection, so that in your CAD or PLC software
> you can invoke the "add a symbol" function and pull up the "symbol
> properties" dialog. <

There is no reason why the symbol editor has to be an integral part of either the CAD or PLC software. If you have used Siemens PLC software, you are used to defining your symbols separately from using them. The CAD or PLC software could call a symbol definition dialog that is actually part of a third program.

> > perhaps even pulling design
> > information from the mechanical drawings. <
>
> Now that'd be really neat
>
> As a pipe dream, this would note the location of motors and limit switches
> and automatically generate associations between them in the PLC programming
> software (including diagnostic messages when the motor should've reached
> the limit switch by now, but hasn't - just fill in the timeout).
<clip>

What you've described is modeling the machine. That isn't what I had in mind. The problem is that the program *is* the logical (if non-graphical) model, and what I had in mind was better integration of the complete design process
which comes before the model is complete.

I was thinking more along the lines of the mechanical designer inserts a new Festo model XX cylinder into the drawing, and includes two MRS switches. He then connects the cylinder to a pneumatic valve on the pneumatic schematics, and associates the MRS switches with the valve states.

The MRS switches and valve go into the symbol list to get assigned addresses by the electrical designer. The PLC programmer sees that there are I/O devices that he hasn't done anything with and sees that the MRS switches are
associated with the valve and how the valve states affects the MRS switches. In other words, changes flow through the complete design rather than tooling, pneumatics, electrical, and programming being separate islands.

If at the end of the process there are any devices that aren't being used (this sometimes happens with superfluous sensors), it would show up on one of the drawings as an installed but unused device. The device could then be
either removed (e.g. a sensor), or marked as spare (e.g. a valve).

What typically happens today is that information gets passed between the mechanical, pneumatic, electrical, and programming tasks on bits of paper, or perhaps in spreadsheets. Then different people manually enter this
information into different programs, and hope that everyone remembers to keep everyone else up to date on any changes they make.

Note that for these discussions the references to PLC could equally apply to soft logic, MMI, SCADA, DCS, or any other type of control system. Field devices could be simple sensors, instruments, and actuators, or they could be motor drives, temperature controllers, or other intelligent devices.

> > Some or even all of the above may not be entirely new. It does seem
> > rather obvious to anyone who has worked in this field. I have seen
> > products which do pieces of it. I haven't however actually seen anything
> > which does all of this. I suspect that the reason for this is the lack of
> > open standard data formats which would enable the exchange of data
> > between software written by different parties. <
>
> Well, the obvious solution is to use open-source software: you can read
> (and reuse) the code which reads and writes their formats, write the bit in
> the middle that manages it all, and even submit patches to them to
> integrate it into their respective menus.
>
> Can we look forward to you announcing this project soon?
<clip>

No. I don't see two open source projects that I am that anxious to tie together in this way yet. But on the other hand now that we've discussed this in public, it's less likely that anyone will be able to get a software patent
on it. I think we've covered the whole field, and even managed to work using "XML" into it as well.

--

************************
Michael Griffin
London, Ont. Canada
************************

 

On February 26, 2004, Jiri Baum wrote:
> > Indeed. The circuit drawing might also be (somewhat) animated, so that
> > the computer would tell you what voltages should be on which wires, in
> > the same way that it does for ladder rungs. (That'd let you troubleshoot
> > by reconciling between what the computer thinks and what the voltmeter
> > says.)

On March 1, 2004, Michael Griffin wrote:
> This would work only for fairly simple circuits, otherwise you would have
> to model the whole machine. This might be more trouble than the end result
> is worth. <

Yes - fortunately, most circuits are fairly simple (and I did say "somewhat" - animate what you can easily, leave the rest).

Modelling the whole machine probably wouldn't be worthwhile unless you had a model left over from the design stage.

> My original thought was that it would give you a device
> information (e.g. brand, model number, rating, etc.) so that you could have
> some basic identifying information available without having to look up the
> electrical schematics and bill of material. <

Yeah, most of the time that's about as much as it would tell you: it should be able to animate it up to the next device, and tell you that info. If it's a pneu valve, it might tell you what kind of cylinder it's connected to (or let
you click on it to go to the pneumatic circuit).

> > > The XML file seems like the obvious and simple choice, but may have
> > > limitations for large projects involving multiple people. The problem
> > > would be in keeping the different versions in sync if more than one
> > > person can edit them. <
...
> If you had to allow simultaneous editing (especially at widely separated
> sites without real time network connections) then you would want some sort
> of document merge facility to reconcile two changed versions. This is
> possibly analogous to merging code trees in a distributed software project. <

You want this feature anyway, because a lot of the time the machine itself is not on the network (or at least not on the same one) and you'll need to reconcile maintenance changes.

> > > Another means might be to have a third application which is used for
> > > creating and editting symbol files, from which both the CAD and PLC
> > > programs import their data.
> >
> > Ideally you want a two-way connection, so that in your CAD or PLC
> > software you can invoke the "add a symbol" function and pull up the
> > "symbol properties" dialog.
>
> There is no reason why the symbol editor has to be an integral part of
> either the CAD or PLC software.
...
> The CAD or PLC software could call a symbol definition dialog that is
> actually part of a third program. <

Yes, that's what I meant. Both the CAD and the PLC software should be able to call up dialogs from the symbol manager.

> > > perhaps even pulling design
> > > information from the mechanical drawings. <
> >
> > Now that'd be really neat
> >
> > As a pipe dream, this would note the location of motors and limit
> > switches and automatically generate associations between them in the PLC
> > programming software (including diagnostic messages when the motor
> > should've reached the limit switch by now, but hasn't - just fill in the
> > timeout).
>
> What you've described is modeling the machine. <

Yes. Like I said, pipe dream.

> I was thinking more along the lines of the mechanical designer inserts a
> new Festo model XX cylinder into the drawing, and includes two MRS
> switches. He then connects the cylinder to a pneumatic valve on the
> pneumatic schematics, and associates the MRS switches with the valve
> states. <

Yes, that's the realistic and right-now version.

> The MRS switches and valve go into the symbol list to get assigned
> addresses by the electrical designer. The PLC programmer sees that there
> are I/O devices that he hasn't done anything with and sees that the MRS
> switches are associated with the valve and how the valve states affects the
> MRS switches. In other words, changes flow through the complete design
> rather than tooling, pneumatics, electrical, and programming being separate
> islands. <

Precisely.

...
> > Well, the obvious solution is to use open-source software: you can read
...
> > Can we look forward to you announcing this project soon?

> No. I don't see two open source projects that I am that anxious to tie
> together in this way yet. <

OK.

> But on the other hand now that we've discussed
> this in public, it's less likely that anyone will be able to get a software
> patent on it. I think we've covered the whole field, and even managed to
> work using "XML" into it as well. <

Hmmph; I incorporate and reallege the above, suggesting that CORBA might be used instead of XML.

I incorporate and reallege the above, suggesting that .NET might be used
instead of XML.

I incorporate and reallege the above, suggesting that Java might be used instead of XML.



Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 

If you are tring to pass the data from the PLC programming software to the CAD package, the easiest way would be to buy a purpose built CAD/CAE system that already has this ability such as Electrical Designer or AutoCAD Electrical. Existing DXF and DWG files can be made intelligent in both of these systems. These two pieces of software hook 100% into AutoCAD.