Announcement

Collapse
No announcement yet.

BRX PLC Issue CurrentPosition Strange Bug (Help BobO!)

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts


  • BRX PLC Issue CurrentPosition Strange Bug (Help BobO!)

    Hi Automation Direct/BobO, I am using a BRX series PLC to control 3-Axis of stepper motors. I am encountering an extremely strange issue where my $Axis2.CurrentPosition is randomly jumping to higher values and then returning to normal.


    This behavior can be seen in the following trend graph. Notice that the values it chooses to jump to are constantly increasing, but not at the rate the actual axis is increasing by. The "CurrentPosition" variable is read only so it seems like the issue isn't solvable by me.


    The other axis are not exhibiting this same behavior, only $Axis2.

    Refer to image 1.


    The next trend graph is the same as the previous except it monitors 3 machine cycles. The red dotted line is where we power cycled the machine (In case it was some issue of integer overflow). Interestingly it reset the random fluctuations and then these fluctuations continued increasing as the same rate.


    Refers to image 2.

    One thing I will say is that my code currently is someone straining the BRX. I set up my own 500us interrupt to allow control over a 4th stepper motor, additionally I also set up a lot of my sensors to react using interrupts so potentially there could be up to 4 interrupts running simultaneously.


    I can attach my code if needed.
    Attached Files
    Last edited by mounky; 02-13-2019, 07:55 PM.


  • #2
    A timed interrupt at 500us is pushing the threshold of what this PLC can handle. Not sure what the actual data glitch is. I'm sure the underlying register is not changing, but the image register copy seems unhappy. If you can give me a program that demonstrates the behavior, I'm happy to look at it and see if it is a bug or pilot error. The most helpful program is one I can stuff in the controller and it just does the thing when it goes to run mode.

    Comment



    • #3
      I have another question about the way the AXVEL instruction works. At what rate does the instruction read from an updated $Axis#.TargetVelocity. I have an input interrupt that is modifying the targetvelocity register.

      Does the axis respond to these updated values at the beginning of the scan, during the scan when the AXVEL instruction exists, or at some other condition?

      Thanks,
      Benny

      Comment



      • #4
        .TargetVelocity is pushed to the Axis Co-processor (ACP) at the end of the scan. The instruction really doesn't do anything but send the appropriate mode change to the ACP, and then monitors the input leg and axis status to send any updates to the ACP. Everything in the Axis structure is handled by the low level I/O driver.

        Not actually sure of the implications of accessing a register like that from an ISR, but my hunch is that it may not be favorable. There really isn't any advantage though, since the update doesn't get pushed to the ACP until the I/O cycle. As a general rule, if you plan on accessing global image register from within an ISR and in the main program, you need to surround the register access (from the main program) with INTSUSPEND/INTRESUME.

        Comment



        • #5
          Originally posted by BobO View Post
          A timed interrupt at 500us is pushing the threshold of what this PLC can handle.
          Really? Why, is there a lot of code he's running on the interrupt? Just in general, a 500us interrupt doesn't seem unreasonable as long as there's not a lot of code.

          Comment



          • #6
            Originally posted by ControlsGuy View Post

            Really? Why, is there a lot of code he's running on the interrupt? Just in general, a 500us interrupt doesn't seem unreasonable as long as there's not a lot of code.
            It can handle 500us fine. He mentioned up to 4 interrupts though, so it mounts up. Depending on how much work he's doing in the ISR, it might be 50us each x4, and now you are eating nearly 50%, before comm interrupts.

            Comment



            • #7
              Ah, OK. Didn't notice the 4x part. 90's SLCs could theoretically do 1ms (only one ISR), but they failed to mention that they had 700-800us overhead per call!! I had like 20us of code, and it still bumped my scan from 15ms to over 60, because of the undocumented overhead .

              Comment



              • #8
                I had 1 interrupt running at 500us and then the other 3 were input triggered. Yesterday I entirely removed interrupts from the machine and everything started magically working perfectly. Who knew that scan based platforms prefer not violating the scan

                I was also moving the $Axis3.CurrentPosition value to a register during the interrupt because I thought that might get me a more accurate position value, however it ended up causing more headache than anything else.

                The reason I started relying on interrupts in the first place was because a thru beam fiber sensor was getting triggered for such a short period of time that the scan would occasionally miss it. I ended up going into the amplifier options and configuring an ON_Delay to give the PLC 20ms no matter how long it was actually triggered for.

                Comment



                • #9
                  Originally posted by mounky View Post
                  I had 1 interrupt running at 500us and then the other 3 were input triggered. Yesterday I entirely removed interrupts from the machine and everything started magically working perfectly. Who knew that scan based platforms prefer not violating the scan
                  Well...yeah.

                  Originally posted by mounky View Post
                  I was also moving the $Axis3.CurrentPosition value to a register during the interrupt because I thought that might get me a more accurate position value, however it ended up causing more headache than anything else.
                  It's legal, you just need to suspend interrupts in main logic while you access. It isn't helpful though. All of the interfacing with the ACP happens during the I/O cycle, so no benefit.

                  Originally posted by mounky View Post
                  The reason I started relying on interrupts in the first place was because a thru beam fiber sensor was getting triggered for such a short period of time that the scan would occasionally miss it. I ended up going into the amplifier options and configuring an ON_Delay to give the PLC 20ms no matter how long it was actually triggered for.
                  The 'proper' way to use interrupts is to catch an event and latch it for main processing. You can do immediate outputs, but only OUTI is useful. Interrupts are super powerful, but only for specific things. The PLC is still scan based, and the bulk of the I/O is scan-synchronous. That really can't ever change.

                  BTW: We have added a Pulse Catch feature ala CTRIO, which will be in DmD 2.4 when released shortly. That would allow you to catch simple switch events without having to use an interrupt.

                  Comment



                  • #10
                    I'd say overall my experience working with the BRX series PLCs has been pretty good. Probably the best value for its functionality and built in IO. Will definitely use it in smaller machines going forward.

                    My biggest complaints/comments are

                    1. "Compiler Error: Trying to AND above a JOIN"
                    The fact that you have to write redundant contacts whenever you want two parallel paths makes the ladder look much less clean. I understand its a compiler limitation and easily worked around but it definitely takes some getting used to.

                    2. Large instructions without ability to minimize or hide.
                    Working with the AXHOME and AXPOSTRAP instructions can become extremely cumbersome as each one takes up a large portion of the ladder. I even tried selecting the "Display Short Summary" option but that didn't fix that. It would be nice if we could either hide individual rungs or somehow minimize the detailed information on these instructions and just see the name and axis.

                    3. Excessively large instructions overall.
                    In general Do More Designer seems to have excessively large fonts and coils/contacts leading to less working space for the programmer. You can zoom out which helps somewhat but that doesn't fix the root issue that the scaling of the coils/contacts just seems wrong. I've mostly worked in Siemens/AB and it there default scaling just feels much nicer.

                    At the end of the day I can't be too bothered by free software and I will happily continue integrating with automation direct hardware.

                    Comment



                    • #11
                      The observation on instruction and font sizes is interesting. I had to go compare the Siemens and Rockwell with Do-more Designer and I don't see any huge differences.

                      Siemens TIA is actually less ladder (network) space due to all the extra stuff it opens around it. Disclaimer: I really don't like Siemens, too different for me. And the math instructions are hideously clunky.

                      Rockwell doesn't seem any smaller than DmD, though I didn't have any motion instructions included to compare size-wise to the Axis types. They definitely fail in wasted menu bar space.

                      But, I also don't leave DMD at it's defaults either. I turn off 3D - even though it doesn't cost any space, it feels cluttered to me. And I have always dropped to 85% default zoom unless my eyes are getting blurrier than usual. Some things are too small font-wise and some maybe too big. I've had my say on some of it a few years ago, and some has improved and some could still use a little help. DmD has some features that I wish Rockwell had - hover over cross reference is one for sure - program rungs with comments in the tree is another.

                      Comment



                      • #12
                        Originally posted by mounky View Post
                        3. Excessively large instructions overall.
                        In general Do More Designer seems to have excessively large fonts and coils/contacts leading to less working space for the programmer. You can zoom out which helps somewhat but that doesn't fix the root issue that the scaling of the coils/contacts just seems wrong. I've mostly worked in Siemens/AB and it there default scaling just feels much nicer.
                        A few universal tweaks you can make that might help:

                        1. Change to 2D drawing. In the Ladder Options dialog, in the Miscellaneous group, change Ladder Tokens to 2D. You may want to tweak the line thickness, which scales based on the current zoom level. Make sure everything is checked in the "Apply to" checklist at the top of the Ladder Options panel, especially New Views.

                        2. Tweak the Default Zoom for New Views from 100% (same dialog/group, same caveat on Apply To New Views). If that doesn't give you want you want, you may want to play with the Font setting in the INI file (see #3).

                        3. Adjust the Workspace Font Size in the INI file. Double click on the DmDesignerX_X.ini entry in the Launch Pad's Applications panel. Look for the [Fonts] group. Change the Workspace Font entry point size from 10 to 9 (or whatever). You may need to shut down Designer and re-launch after tweaking that for it to apply.


                        There are 10 kinds of people in this world, those who know binary, and those who do not.

                        Comment



                        • #13
                          I turned off 3D and set it to 85% scaling and it definitely gives the ladder a much cleaner clearer look. Before I posted I compared Logix5000, Tia Portal, and DoMore and all three had basically the same working space and rung size.

                          The 3D kinda gives everything this cramped feeling, which functionally doesn't change much in terms of space, but was definitely the reason for me thinking the scaling was off.

                          Thanks users!

                          Comment



                          • #14
                            We probably should revisit the display sometime soon, and see if we can make the default view be pretty but less 'full figured'.

                            We also have plans for a single line mode for large boxes, that will greatly improve screen usage for complex boxes. We are also thinking of allowing you to click on a one-line version and switch that box back to the full version, or maybe even a hot-key toggle.

                            Comment

                            Working...
                            X