bfitz (Customer) asked a question.

Casting stage bits

I was hoping to cast stage bits like InsertProgramName.S0:SD, or InsertProgramName.S0_15:SD in an instruction, but it doesn't seem to work. Any particular reason? I'm looking to use the ENCO instruction to spit out a number corresponding to the active stage in a program (only one stage active in the 0-31 stage range by design) and was being lazy and trying to avoid an intermediate instruction.


  • HOST_BobO (AutomationDirect)

    Casting structure fields isn't possible at this time, due to internal limitations I won't bore you with.

    Selected as Best
  • HOST_BobO (AutomationDirect)

    Casting structure fields isn't possible at this time, due to internal limitations I won't bore you with.

    Selected as Best
  • bfitz (Customer)

    Ok. I figured if it was something that was possible, it would have been available already.

     

    Thanks!

  • HOST_franji1 (HOST Engineering)

    StageENCO1I recently used ENCO for that exact same function in a program that just sequences and loops back, no parallel diverging/converging. I only had a handful of stages so the .S0_15 worked. I also realized that I had to handle -1 when the specific stage program code-block wasn't running yet (i.e. when ENCO finds no "1").

     

    I have it in a Trend View pane that shows the sequence - works great! (note: the program settles only in stage S2 and S3, other stages are one-scan type transitions).

     

    Expand Post
  • bfitz (Customer)

    Yeah, the -1 thing surprised me a bit, but I don't really know what it was I was expecting. A mention in the help file might be good. I'll probably just leave the -1 in my case, and use it as 'this program isn't running' indicator. In my case, I skipped Stage 0, as I was planning on a zero be the 'program not running' indicator. I'm also using some other logic to jump to specific stages, and I'm using 0 to indicate 'no current command to jump'. I suppose I could have used -1 for that indicator, but 0 seemed more intuitive at the time.

     

    Side note: I'm annoyed at the fact that there's no StageSetIndexed command that would work outside of a stage. The JumpIndexed command saved the day, but it's annoying that it needs to be in a stage (understandable, but annoying). I put the JumpIndexed command in it's own stage, right behind a StageResetRange command to clear all running stages. I also Set the JumpIndexed stage so it stays running. That, plus a Program.FirstScan rung to activate the old initial stage (JumpIndexed stage is the new initial stage) is a workable solution. More than one way to skin a cat with just about every situation in the DoMore. :)

    Expand Post
    • HOST_franji1 (HOST Engineering)

      I see. You need a SGSETI at the top of your program code-block. That sounds very do-able.

  • bfitz (Customer)

    SGSETI workaround

    The workaround isn't too bad. It's just an extra stage, the first rung in the picture (starts the old Initial stage), and the SGSET instruction in the second rung to keep the JMPI from killing the stage it's running in.

     

    That said, if you want to add a new instruction, I'm not going to mind ;)

    Expand Post
    • HOST_franji1 (HOST Engineering)

      It's JMPI that does a SGSET instead of a JMP. Easy peasy. One key thing is that SGSETI could exist OUTSIDE a SG (like SGSET can).

  • bfitz (Customer)

    New Do-More instruction does this one weird trick!!

     

    The announcement writes itself, really 😅