News:

  • May 02, 2026, 03:11:01 AM

Login with username, password and session length

Author Topic: HELP! Modbus Protocol  (Read 27745 times)

ATU

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 2126
  • YKPAIHA
    • ATU, Inc.
HELP! Modbus Protocol
« on: July 02, 2012, 10:30:46 AM »
I am using the Modbus TCP/IP IBox Instructions to Read and Write to several devices. They are active all the time at the top of my stage program. Unfortunately, the constant communications are having an adverse effect on the device I am coummunicating with.  I need to shut it all off or pause it in an orderly manor and turn it back on during a part of my machine cycle. Is there a repeatable way to do this without risking a hangup?  Maybe manipulate the work registers?

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6154
  • Yes Pinky, Do-more will control the world!
Re: HELP! Modbus Protocol
« Reply #1 on: July 02, 2012, 11:08:31 AM »
I always have quick answers for MX, which gives me great confidence that we have a great product.

No clue about DL though...
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3806
    • Host Engineering
Re: HELP! Modbus Protocol
« Reply #2 on: July 02, 2012, 11:10:31 AM »
Can you just monitor the success and fail bits, use those as an interlock to either
1. start the request again
2. jump out of the stage

ATU

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 2126
  • YKPAIHA
    • ATU, Inc.
Re: HELP! Modbus Protocol
« Reply #3 on: July 02, 2012, 11:13:35 AM »
I talked with AD tech support, they suggested disabling all the IBOX instructions on the rising edge of the success or Fail bit of the last Modbus IBox instruction in the chain. If they are all interlocked and execute in that order, shouldn't that work?

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3806
    • Host Engineering
Re: HELP! Modbus Protocol
« Reply #4 on: July 02, 2012, 11:23:22 AM »
You basically need to control all the interlocking inter-IBox.  You cannot rely on the built-in token passing that "just works" with an ST1 driving a bunch of your ECRX/ECWX instructions.

Once you have that working (completion of first drives the enabling of the 2nd, completion of the 2nd drives the completion of the third, ... completion of the last drives the completion if the first), add a PAUSE C-bit that interlocks EVERY IBox enable leg.  Whenever the PAUSE bit comes on, the current one finishes, and the "next" one has all logic in its enable leg ON, EXCEPT for the PAUSE bit (basically an ANDN PAUSE nc contact).

Once the PAUSE bit turns OFF, that point in the round-robin will start up and go.

ATU

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 2126
  • YKPAIHA
    • ATU, Inc.
Re: HELP! Modbus Protocol
« Reply #5 on: July 02, 2012, 11:34:48 AM »
Not quite sure I have it visualized, but from what you said earlier, if I put each IBOX in its own stage and use the Success/Fail bit to move on to the next. Then just add one additional stage with a pause latch bit to prevent it from continuiing to the beginning.  Start that chain of stages out of the ISG and don't allow anything else to control it except for the pause bit. That should work and not hang?

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3806
    • Host Engineering
Re: HELP! Modbus Protocol
« Reply #6 on: July 02, 2012, 11:45:45 AM »
I did not know the resolution of your PAUSE - I was assuming that you would need it to PAUSE at the NEXT IBox, not the NEXT PASS.

So having a PAUSE interlock on the LAST SG to start the NEXT PASS should work.  However, you must have that logic I mentioned on a different forum post to initialize ALL SG IBox workspace registers to 0 on PGM->RUN (SP0).

ATU

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 2126
  • YKPAIHA
    • ATU, Inc.
Re: HELP! Modbus Protocol
« Reply #7 on: July 02, 2012, 02:46:55 PM »
It seems to be working and not hanging up, however, seems like I'm not getting the correct data as I should. Do I need to stay in the stage until the Sucess or Failure bit comes on and goes OFF, then Jump?  Now I'm jumping only on the rising edge and I am wondering if the Sucess bit is staying on?

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3806
    • Host Engineering
Re: HELP! Modbus Protocol
« Reply #8 on: July 02, 2012, 02:51:09 PM »
Definitely need to let the IBox finish, so transition out of the stage after success or failure - don't forget to RESET those bits in the "destination" stage cuz there's nothing to turn them OFF.

ATU

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 2126
  • YKPAIHA
    • ATU, Inc.
Re: HELP! Modbus Protocol
« Reply #9 on: July 02, 2012, 02:52:07 PM »
Thanks, I'll bet that's the issue

ATU

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 2126
  • YKPAIHA
    • ATU, Inc.
Re: HELP! Modbus Protocol
« Reply #10 on: July 02, 2012, 05:31:59 PM »
I put the pause latch check in the first stage of my chain of IBOX instructions, along with a reset for all the success and fail bits. At the top of the program before the ecom instruction, I put the reset for all the work registers enabled by the SP0 bit. It all works without any hangups and I did several power up cycles and PRGM/Run transitions.

Just a note for anyone else running into this problem on the Cognex 1400 series Cameras. There is definitely an issue with Modbus communications and missed triggers. I increased the Buffers, but it still did not help.  I am sure that it is because of the combination of circumstances that is causing this, but only after I stopped communications during the acquisition phase, did it stop missing triggers.

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3607
  • Darth Ladder
Re: HELP! Modbus Protocol
« Reply #11 on: July 02, 2012, 09:33:41 PM »
Good to know!  I have a Cognex camera in an upcoming project.
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.