News:

  • July 03, 2026, 05:31:36 AM

Login with username, password and session length

Author Topic: Edge ID comparisons  (Read 9135 times)

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3619
  • Darth Ladder
Edge ID comparisons
« on: August 06, 2015, 02:06:37 PM »
I really like the ability to ignore edge IDs during a compare since they generate a lot of meaningless differences, hundreds in some cases, but is there a way to do so in the compare that's initiated when going online, as opposed to invoking it from the menu?  I went online with a DM this morning and don't recall seeing that option anywhere.

I'd like to request that, or better yet, a global user config setting to make ignoring the default and just do that for all compares without having to select it each time.
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3833
    • Host Engineering
Re: Edge ID comparisons
« Reply #1 on: August 06, 2015, 02:23:16 PM »
If you are getting that many differences, you need to "resync" (i.e. just save the project to DISK whenever you shut down). 

But we can add something to the Global Options to enable that option by default to fix the symptom.  But again, if you get that a lot, there is a reason for it.

If you do RUNTIME edits with your DISK-based projects (not PLC-based project), those differences are not meaningless.  Every single one of those instruction "edge" states will return back to the "home" state and possibly immediately re-fire all those instructions on the scan when the RUNTIME edit is downloaded and the bumpless "switch over" from the old program to the new program occurs.

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3619
  • Darth Ladder
Re: Edge ID comparisons
« Reply #2 on: August 06, 2015, 05:30:39 PM »
If you are getting that many differences, you need to "resync" (i.e. just save the project to DISK whenever you shut down).

I think this particular case is probably anomalous. It's an upload from one processor, subsequently downloaded to another.  Probably renumbered the edges somewhere in the process.

Quote
But we can add something to the Global Options to enable that option by default to fix the symptom.  But again, if you get that a lot, there is a reason for it.

If you do RUNTIME edits with your DISK-based projects (not PLC-based project), those differences are not meaningless.  Every single one of those instruction "edge" states will return back to the "home" state and possibly immediately re-fire all those instructions on the scan when the RUNTIME edit is downloaded and the bumpless "switch over" from the old program to the new program occurs.

Thanks.  Understand that they're not meaningless in the strictest sense.  I think the scenario you outline is uncommon enough, though, that it's probably preferable to leave edge detection off as a default, or at least permanent user option.
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3833
    • Host Engineering
Re: Edge ID comparisons
« Reply #3 on: August 06, 2015, 05:41:41 PM »
Do you at least want to know that they are different (the Boolean flag, not the list of 100 instructions)?  Or would you rather flag that they are the same, even when they are not?  That is, at the instant you connect, when you have this option to "ignore edge/instruction ID differences", and if that is the ONLY differences between the two, you just want to connect and not be bothered at all.  I'm guessing you probably want the latter (don't bother me, kid)?

This option would be for the handling of ALL project connections (a Global option), not a project specific setting.

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3619
  • Darth Ladder
Re: Edge ID comparisons
« Reply #4 on: August 06, 2015, 05:51:42 PM »
Do you at least want to know that they are different (the Boolean flag, not the list of 100 instructions)?  Or would you rather flag that they are the same, even when they are not?  That is, at the instant you connect, when you have this option to "ignore edge/instruction ID differences", and if that is the ONLY differences between the two, you just want to connect and not be bothered at all.  I'm guessing you probably want the latter (don't bother me, kid)?

This option would be for the handling of ALL project connections (a Global option), not a project specific setting.

Option 1 sounds like an excellent idea (notify about edge differences but don't list).  That way, you know there ARE edge differences, and can investigate if you think it necessary, but it doesn't overwhelm the other code differences in the display, and you can find them, if any.  And yes, I'd prefer it be global. In fact, if you include a button to enumerate the differences, you might not even make it an option.  Just list non-edge differences plus display whether edge differences exist, with a button to list them (either a dedicated edge difference list or just add to the main list).

Also, can you explain to me why and how they get unsynched if you only use the toolbar Save and Write, as opposed to Save Project As?
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3833
    • Host Engineering
Re: Edge ID comparisons
« Reply #5 on: August 06, 2015, 08:06:37 PM »
Many ways that this can happen.

Scenario #1:

Project A is in PLC in RUN mode.  It has Edge Bit 5 and Instruction ID 4.

Project B on Disk is opened.  It is different than what is in the PLC.  It has different instructions, but they happen to use Edge ID 5 and Instruction ID 4.  You write this to the PLC in RUN mode.  Because those Edge/IIDs were ACTIVE in RUN mode in Program A, we must CLEAR those in the specific instructions that have the same (but not identical) instructions in Program B.  So at download time, Program B's program changes those and downloads B with NEW Edge ID and IID for those 2 instructions.

Output Window notifies you of this fact (that Edge IDs and IIDs have been changed).  This means that what is on DISK is DIFFERENT (that STILL has the "old" Edge/IID).  When nagged at closing about the fact that the disk project is different (but I did not change anything, but you actually did - see output window reference), you do NOT save it to disk.

Scenario #2 (probably more common)

Project A is in the PLC.  You make a change to the program, adding a new instruction that has an edge bit or IID.  You save it to disk first, THEN you write it to the PLC.  At download time, the new instruction got assigned a new Edge and/or IID and you are notified via the Output Window that these got assigned and the program was changed.  This means that what is on disk is different (it has the unassigned Edge/IID) than what is in the PLC.  When nagged at closing about this difference, you do NOT save it to disk.

Scenario #3 based on what you are describing what you are doing:
If you are writing the same disk project in different PLCs that have different projects, and you are doing a RUN mode update, any duplicate Edge and IIDs must be remapped based on the old PLC project's usage of Edge and IIDs.  So with different PLCs with different Projects, but downloading from the SAME DISK project, in RUN mode, those can be completely re-mapped and be completely different.

I know this is clear as mud.  The key point is that RUN mode edits are CRUCIAL for those who really need it to behave truly "bumpless".  I can't have a STREAMOUT instruction with IID 5 in scan 1234 be pending during a RUNTIME edit, and when that asynchronous instruction finishes, IID5 is now tied to a STREAMIN instruction with the same IID (bad things will happen) at scan 1235.  The IIDs are there SPECIFICALLY to ensure that RUNTIME edits don't mess things up.  Edge Bits are similar, but they also maintain the "edge state".