• Bpod

  • using all serial ports of RE module, v1

Hi Josh,
We have a Rotary Encoder Module (Teensy 3.5 or 3.6), which communicates with the State Machine through Serial1.
We need to use the RE Serial2 port to send bytes directly to a Valve Driver Module.
We have been trying the following simplified code loaded into the RE, but the Valve Driver Module receives no communication.
Valves do open if we connect the Valve Driver Module to the State Machine and send messages from there.
We have tried different RE modules, but none worked.

Do you have any insight into what might be happening and whether we should be able to set this communication up?

Thanks a lot, as always!

#include "ArCOM.h"
#include "Arduino.h"
#include <SPI.h>
ArCOM OutputStreamCOM(Serial2);

void setup()  {
    Serial2.begin(1312500);
}

void loop() {
    for ( int i = 0; i <= 7; i++) {
        int byteCurrentZone = 1 << i;
        OutputStreamCOM.writeByte("B");
        OutputStreamCOM.writeByte(byteCurrentZone);
        delay(500);
    }
}

Hello Paola,

Bpod's RS-485 module connection is polar. This means that the wiring is different on the state machine side (S) and the module side (M).

The second port provided on some modules was set up with the following convention:
Modules that capture streaming data (Analog Input, Rotary Encoder): M-type
Modules with streaming output (Analog Output, DDS): S-type

The valve driver module is M-type, and unfortunately so is the Rotary Encoder's 'Module' port, so they cannot communicate directly.

Depending on your application you may be able to accomplish what you're trying to do by having the state machine act as a relay. It can set the valve driver module when the rotary encoder module returns an event. You can mitigate interruption of the flow of states using the >back command (example here), and use global timers instead of state timers (which reset each time you re-enter the state).

Please let me know whether this works for you.

Thanks,
Josh

Hi Josh,

Thanks a lot. This was indeed the piece of information that we were missing.

Using the state machine as a relay would not work with our application. We need to specify which of many valves to open.

However, we found in the meantime that pins 2, 3, and 7 of the Valve Driver module appear to be free. Can you please confirm this?
If so, we would use them to receive parallel communication from the rotary encoder.

Could you please also clarify the role of pin 4 in the Valve Driver?
Currently, it seems to be always ON. Would we be able to turn it temporarily off (through BNC1 event from the state machine) to prevent the valves from opening?

Thank you.
Paola

Hi Josh,
I'm just following up on my last message. We have successfully implemented parallel communication with pins 2, 3, and 7 of the Valve Driver module. It works like a charm, so all our problems are now solved.
Thanks, and have a nice day,
Paola

4 days later

Hi Paolahydra,

I'm glad you were able to solve this!
Pin 4 on hardware v1 (Pin 7 on v2) is the "enable" pin, which enables power to the valves.

-Josh