"Control a Device" window not working?

This was brought to my attention by a co-worker working on a Massio RPM system, but... the upshot is that "Control a Device" window doesn't seem to be working, at least for sending strings. We can try sending strings to a serial port (I've tried doing this to several different systems now, never get any notifications strings go in or out), but the notifications window never shows any strings out or in from the RS232 port. It's been so long since i've used that function in NetLinx Studio that I'm once again flummoxed, can't figure out why it isn't working.

Comments

  • fogled@mizzou[email protected] h4x354x0r Posts: 547
    Side quiz: how many of you know what device that command is trying to control?
  • ericmedleyericmedley Senior Member - 3709 Posts Posts: 4,152
    i do know that when duet or whatever the new module environment they use with RPM and will probably announce later this month at Dev Con, can sometimes 'hijack' the port in such a way that it is no longer reachable via NS or its attendant controlling apps.
  • rogerroger Junior Member Posts: 4
    Try formatting your string as
    "'>1P1',$0D"
    
  • fogled@mizzou[email protected] h4x354x0r Posts: 547
    Tried this on a couple older systems running pure old school Netlinx code, no Duet anything, dirt old firmware version. Still no luck.

    Tried correctly formatting the string (D'oh!), still no luck.
  • zack.boydzack.boyd Smacks Keyboard Repeatedly Posts: 94
    Just curious - how are you testing? Are you using a loopback? That might help. You won't see your strings going out in notifications....
  • Joe HebertJoe Hebert Junior Member Posts: 2,154
    zack.boyd wrote:
    Are you using a loopback? That might help. You won't see your strings going out in notifications....

    Correct, you won't see strings go out from Control A Device in Notifications but they are going out and you will see feedback if the device is returning strings. Loopback is good advice as well. Assuming of course that the 232 port has feedback enabled by either having a STRING: DATA_EVENT or RXON has been issued to the port or CREATE_BUFFER is in play. Also assuming the 232 port is not malfunctioning due to a dried out capacitor.

    Control A Device for RS-232 ports works perfectly fine, use it all the time.
    I'm once again flummoxed

    You should probably see a doctor and get that checked out as a precautionary measure.
  • fogled@mizzou[email protected] h4x354x0r Posts: 547
    Joe Hebert wrote: »
    Correct, you won't see strings go out from Control A Device in Notifications but they are going out and you will see feedback if the device is returning strings.

    That's the answer I was looking for. I consider it irritating and nonsensical that it won't show what's going out of the port under those conditions, but as long as I know that's how it works, I can deal with it. The only piece of the puzzle that didn't fit was that the device does return strings from programmed code, but I didn't see anything coming back from the device when I send the same command using Control a Device. I just re-tried it, and it looks like we never had the string formatted correctly in earlier tests. All the other failed tests were some other version of Joe's information as well; using a port that didn't have any handling code, etc.
  • MLaletasMLaletas Junior Member Posts: 219
    If the 232 port doesn't have a string block on it it will not automatically post responses in notifications, you can manualyl do it by sending a command to the port RXON
Sign In or Register to comment.