News:

  • May 31, 2026, 10:08:21 AM

Login with username, password and session length

Author Topic: RBE ACK via Visual Basic 6?  (Read 15887 times)

Buzz

  • Newbie
  • *
  • Posts: 5
RBE ACK via Visual Basic 6?
« on: September 14, 2010, 06:17:43 PM »
Is it possible to send an acknowledgment back to the ECOM100 after it receives data from an RBE, sending the ACK via Visual Basic 6?  My VB app is receiving the RBE data along with the 13 bytes of protocol data, followed by our internal data. . . But V3000 always reports (A) indicating an error (Timeout waiting for ACK or response)??

Greg

  • HostTech
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 702
  • Hmmm...
    • Host Engineering, Inc.
Re: RBE ACK via Visual Basic 6?
« Reply #1 on: September 15, 2010, 10:06:11 AM »
Buzz, I don't know how to send an ACK back with VB6, however, in the RBE header in the PLC, it is possible to set it such that the RBE does not require an ACK from the PC. Have you tried that?
There are two types of people in the world; those that can extrapolate from incomplete data sets.

Buzz

  • Newbie
  • *
  • Posts: 5
Re: RBE ACK via Visual Basic 6?
« Reply #2 on: September 15, 2010, 11:30:56 AM »
Our usage of the ECOM100 will be in an unattended environment. There won't be anyone actually viewing or interacting with the server application that communicates with the ECOM.  Others involved want a way to know, with certainty, that our server application is still running / functioning correctly.  I have thought the same that you suggest, configuring the ECOM to not require an ACK.  In fact, even when it does expect an ACK and doesn't receive one, when V3000 goes to (A), the ECOM still seems to function and go about its business.

Anyway, I was hoping someone there might know if the ACK (via Visual Basic 6) should be sent back through the same socket the RBE was received on or if the ACK should be sent back using HEICCMRequest and if there is anything in the first 13 bytes of RBE protocol data that should to be used to send the ACK, particularly if bytes 4 and 5 are of any significance? And if the ACK is simply the string "Reply: #" where # might be resolved by using data from the 13 bytes of protocol data?  And umm, I was also wondered if the ACK was sent via HEICCMRequest, is there a particular address it should be sent to? Sigh, I feel like I'm rambling :-X