News:

  • October 12, 2025, 06:42:57 PM

Login with username, password and session length

Author Topic: Is it possible to do Documentation by ROW?  (Read 7788 times)

AZRoger

  • Jr. Member
  • **
  • Posts: 18
Is it possible to do Documentation by ROW?
« on: August 06, 2008, 02:20:29 PM »
Hi. I just wrote some ladder to convert from IEEE floating point 32-bit to BCD 7.1 digits.
The result was one rung with 30 rows for 42 programming words. I added comments by hand to the exported text file for posting on the AD forum.
I would really like to document each row. But I would also like to avoid adding 29 contracts, and 29 more words of program memory, to make it into 30 rungs. So here are some dobservations/ideas/questions.
Observation: The first rung of a stage will run without any contact to "make it go".
Observation: There seems to be nothing in the Mneumonic Code that "stops it" at the end of a rung.
Question: Is it just good coding practice that forces each rung to start with some sort of contact?
Question: Or can I just start a rung at the power rail and have "boxes" execute?
Question: Does Master Line (MLS/MLR) logic help at all?
Question: Does anyone have a good way to apply detailed comments to Rows of a Rung?
Roger

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3761
    • Host Engineering
Re: Is it possible to do Documentation by ROW?
« Reply #1 on: August 06, 2008, 03:52:22 PM »
Rungs are a Human/PC/DirectSOFT concept.  The PLC has absolutely no concept of what a "rung" is.  It ONLY knows PLC instructions.  Hence, you can enter a 4 word program with a handheld in mnemonics and it make absolutely NO sense as a Ladder rung (e.g. ANDSTR ORSTR OUT ANDSTR), but it will execute!

Except for a few IBoxes and immediately after a SG/ISG instruction, you should always have a contact (probably STR SP1).  Even if DirectSOFT shows it as just an Output coil, it really is basing the status on the top of the boolean stack from the previous rung.

STR X1
OUT Y0
NOP
OUT Y1

Y1 will be ON based on X1, even though in DirectSOFT it looks like Y1 is tied to the power rail.  Bad form?  You betcha!  But we have to allow the OUT Y1 cuz you just may be getting ready to put a SG SG1 after the NOP.  DirectSOFT is a Rung based editor.  Iter-rung dependencies fall on the user (e.g. if you create an SBR, you are also responsible for entering the RT, wherever it needs to go).

So you technically COULD stick NOP between each Output instruction, and there would be separate rungs, but the execution condition would be based on the "first rung" of this "expanded out" rung.

AZRoger

  • Jr. Member
  • **
  • Posts: 18
Re: Is it possible to do Documentation by ROW?
« Reply #2 on: August 06, 2008, 06:32:32 PM »
Ahhh, the BOOLEAN STACK.   :)
My 30 boxes only deal with the ACCUMULATOR STACK.
So if I'm very careful, and put warnings in the comments, I should be able to "expand out" my logic.
I'll rework the IEEE conversion thing this new way and post it here (for general programming {bad?} style) and on the AD forum when it's back online.
Thanks.

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3761
    • Host Engineering
Re: Is it possible to do Documentation by ROW?
« Reply #3 on: August 06, 2008, 07:24:28 PM »
Those instructions look at the boolean stack for execution, though.  The NOP, does just that, nothing, so the boolean stack is left pristine.  So

STR X1
LD V2000
NOP
ADD V2001
NOP
SUB V2002
NOP
MUL V2003
NOP
OUT V2004
will look like 9 rungs, but will actually only execute all of the accumulator boxes only when X1 is ON

AZRoger

  • Jr. Member
  • **
  • Posts: 18
Re: Is it possible to do Documentation by ROW?
« Reply #4 on: August 06, 2008, 07:51:32 PM »
First I tried a method that would expand the rung without using any program memory. It didn't work.  :(
Here what I did: I split off the last box (OUTD) and put it on it's own rung with a comment and accepted the changes.
Then DirectSOFT took the OUTD and added to the end of the prior rung (functionally equivalent) and combined the comment with the comment on the prior rung (it didn't get lost  but it's a couple pages away from the logic it describes).
DirectSOFT does force the ladder to look "normal" and in proper form. Bad style is not allowed. ;)

My best solution, for now, seems to be adding NOPs, as you describe above. These are faster then the actual STR B10101.15 that actually controls execution. I can put the "SPECIAL LOGIC WARNING" comment on the NOPs and keep the FUNCTIONAL comments on the accumulator operation rungs. I'll post that version when it's ready. Thanks again for your help.

I guess I now have a request for new function in DS to allow comments on rows, without using extra words of program memory.

It might not be too hard to let rungs with documentation stay separate. The mnemonic would have comments interspersed with operations. If the code generator can handle NOP followed by OUTD, then it might not choke on this either. I'll post a sample for consideration after I do the NOP style documentation.

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3761
    • Host Engineering
Re: Is it possible to do Documentation by ROW?
« Reply #5 on: August 06, 2008, 10:34:31 PM »
Don't forget that rows transcend the input area too, so how should it handle parallel lines in the middle of your row comments???

              COMMENT FOR ROW 0
   X0      X1      X2      X3      X4        Y0
+--] [--+--] [--+--] [--+--] [--+--] [--+--( OUT )
|       |       |       |       |       |
|       |     COMMENT FOR ROW 1 |       |
|  X10  |  X11  |  X12  |  X13  |  X14  |    Y10
+--] [--+--] [--+--] [--+--] [--+--] [--+--( OUT )
|       |       |       |       |       |
|       |     COMMENT FOR ROW 2 |       |
|  X20  |  X21  |  X22  |  X23  |  X24  |    Y10
+--] [--+--] [--+--] [--+--] [--+--] [--+--( OUT )
|       |       |       |       |       |
|       |     COMMENT FOR ROW 3 |       |
|  X30  |  X31  |  X32  |  X33  |  X34  |    Y10
+--] [--+--] [--+--] [--+--] [--+--] [--+--( OUT )
|       |       |       |       |       |
|       |     COMMENT FOR ROW 4 |       |
|  X40  |  X41  |  X42  |  X43  |  X44  |    Y10
+--] [--+--] [--+--] [--+--] [--+--] [--+--( OUT )

AZRoger

  • Jr. Member
  • **
  • Posts: 18
Re: Is it possible to do Documentation by ROW?
« Reply #6 on: August 08, 2008, 11:17:48 AM »
OK. I will assume your question is one of graphical presentation in ladder view. There's a hidden question too: where do we place the comment in the mnemonic representation?

So let's start with mnemonic view. I think your very dense rung would look like:
STR X0, OR X10, OR X20, OR X30, OR X40,
STR X1, OR X11, OR X21, OR X31, OR X41, ANDSTR,
STR X2, ...
... , OR X44, ANDSTR,
OUT Y0, OUT Y10, OUT Y20, OUT Y30, OUT Y40

The mnemonic sequence is columns first, then rows. Each row appears 5 times! So getting a proper association of the comment to the row gets hard. The comment has to appear between mnenomic lines. In the example above, where the commas separate the operations. This suggests that it would be easier to map comments on contacts, coils and boxes rather than on rows.

Given that the comments will appear between operations in the mnemonics, then ladder view comments should appear "near" the contact, coil or box it applies to.

Taking one step back, Nickname, Wiring Info and Description appear above the Element Name in ladder view. Each of these is presented full width. And space is provided for all three lines above the element name. The ladder diagram is spread out so that none of the lines go through any of the text.

Accumulator Boxes also show the element name and the nickname, wiring info and description inside the boxes. IBOXes show only the element names. For multi-element contacts like the comparison contact, you can provide comments for both elements being compared, but you can't provide a comment for the comparison operation itself or for any constants used.

Back to the ladder view question on how to handle vertical lines in the middle of a row comment.
First off, let's consider them operation comments or reference comments rather than row comments.
If the operation is a box or a multi-element contact, I'd suggest adding the comment above the nickname, wiring info and description for the element(s) referenced. For contacts and coils, I'd spread the lines to avoid overlap. For boxes, I'd keep the comment inside the box. For both placements, I'd like support for multi-line comments similar to the support for ctrl-k rung comments. This would allow for narrower lines in ladder view by putting the comment in a small paragraph rather than one long line.

For entry of the comments in ladder view, I'd suggest using ctrl-{something} using the cursor position to determine which contact, coil or box to apply the comment to. This would also determine where the comment would be inserted in the mnemonic view. And placement in the mnemonic view would signal where to put in the comment in the ladder.

The absolutely most common operations are AND and OR. These are represented by lines in ladder view. The cursor cannot actually be positioned on one of these. I have no suggestion on how to add comments to these. However, I don't see much need. A comment could be placed on the participating contact(s) if an explanation is required.

This feels like it would be a non-trival to implement. It's been a long time since I did lines-of-code estimates for new software functions. Even with excellent object oriented code with good inheritance, this is going to hit several places in the program. It might be easier to just not collapse rungs when the second one has a comment.  :)

As I thought about your question, I ran into an avalance of things to consider. But that's why we ask questions isn't it - to trigger thought about answers. I hope this is useful input.

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3761
    • Host Engineering
Re: Is it possible to do Documentation by ROW?
« Reply #7 on: August 08, 2008, 02:48:34 PM »
I don't think there is a good, clean, easy way for the user to use it, or for us to implement it  ???

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3601
  • Darth Ladder
Re: Is it possible to do Documentation by ROW?
« Reply #8 on: August 08, 2008, 07:23:43 PM »
Allen Bradley has what they call "Address" comments, so the same string occurs everywhere C0 is referenced for example (NO, NC, COIL, SET, etc).   They also have "Instruction" comments which attach to the use of the given address with a given type token, so a given comment would only appear at a normally closed C0 contact for example.

In my experience the instruction comments are totally useless and I never use them.  I use pretty verbose element descriptions and the intent of the rungs should be obvious.  Then I use rung comments if a given rung is non-obvious, if that rung is especially critical, or to set off blocks of related rungs.
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.

AZRoger

  • Jr. Member
  • **
  • Posts: 18
Re: Is it possible to do Documentation by ROW?
« Reply #9 on: August 19, 2008, 10:21:08 PM »
I think the "Address" comments, as Contols Guy describes, are what DS5 (and predecessors) provide with Element Nicknames, Wiring Info and Descriptions. I agree that "instruction" comments appear not be useful at all.

As I promised earlier in this thread, I have re-worked the IEEE Float to BCDx10 example to
(a) improve documentation that would actually appear in Ladder View and
(b) follow the rules about having a contact at the beginning of each rung.
It can be viewed on the new AD forum site at http://forum.automationdirect.com/showthread.php?t=3240

I still think there is value to having comments by BOX. It should not be hard for users to understand and use. Boxes are already "completely different" from coils. Adding a general capability of "comment" at a high level in the object hierarchy should allow (relatively) easy implementation that could be inherited by all BOXes. Being able to describe why a BOX is doing something has value beyond what is available from RUNG and ELEMENT documentation alone.

Still hoping, Roger