An update – I have some LabVIEW code that sends a DIO true/false value depending on a button press, recieved by the Arduino on a digital pin, and blinks the light on the Arduino and also prints out the high/low value (simple test), slowed down to 1/2 second cycle. Currently I’m getting a semi-random highs/lows, even without pressing the button, which I’m guessing is LV’s issue, not continually sending the true/false signal? Unfortunately, I lost my LV computer so I can’t check it – maybe I can schedule for a 3 am session? :ahh:
If you haven’t opened the IO port in your code, I think it may leave the signal pin floating. Does it work when you press the button, or does it ignore the button as well?
I think it’s opened once in the Begin.vi (the computer got grabbed so I can’t look at the code at the moment), and just referenced during the button pressing, and not open/send/closed each time.
There was no discernable difference when the button got pressed.
Consider the fact that a boolean on the PPC is 4 bytes. Also consider the fact that the Arduino uses little endianness. I am not sure about the PPC on the cRio, it might be a big endian, that might bring up some troubles.
But aren’t they both using an on/off electical signal to talk between them? Not code.
(Pay Per Click?)
Well, Boolean only takes up 1 byte (8 bits) in Arduino, the PPC uses 4 Bytes instead (the PPC registers are 32bits). Sending over a boolean from the PPC sends 32 bits of data. Now, considering that you can’t fit 32 bits in a 8 bit register, you have to cut the extra data off using some bit manipulation. And the other problem I was pointing to was that the PPC usually are Big endian, but they can be bi (so it can be both, just not at the same time) that means the bits read from left to right, but the little endian reads right to left. So you need to do some switcharoos there.
So on the cRio a “true” would be represented as:
0000_0000_0000_0001B (if big endian)
0001_0000_0000_0000B (If little endian)
Note: I might be wrong about the above regarding the binary
on the Arduino, you need to just take the last 4 bits so it becomes:
0001B
Every microprocessors have millions and billions of transistors, they all use electrical signals.
Now, if there are any veterans here, feel free to rebuke me. I am a student, I make mistakes and then learn from them.
Setting a TRUE output on a DIO slot sends 5V of power down the wire. That’s one bit, not 32. He’s planning on using four DIO slots to send 4 bits of data to the arduino.
Just a note, you can put the PWM cable in sideways on the signal so you use two cables instead of four.
Can you put a multimeter on the slots? Can you post the arduino sketch?
Oh, then NVM me, I thought he was sending data through ethernet
This sounds VERY much like your pin is floating. This is not really a programming issue, but a wiring/electrical issue.
Watch this video, note why he uses the resistor. If you get it, good, otherwise, I’ll explain:
Originally Posted by Roger
But aren’t they both using an on/off electical signal to talk between them? Not code.
Yes and no. The cRIO will send out an on/off electrical signal, but the Arduino DIO pin does not “sense” “on or off.” It senses 5v or Ground. If you hook it up to nothing (what you may call “off”), it will basically sense the voltage of the wire/air that it is connected to. Ever looked at a volt meter when you haven’t yet hooked it up to a power source? It wanders all over the place. This is what your Arduino DIO pin is doing. It could be anything, high or low. You need to use a resistor to specifically connect the DIO pin to Ground when it isn’t sensing a 5v from the cRIO DIO pin. This is called using a pull-down resistor (not to be confused with a pull-up resistor, but similar idea).
Do you have a mentor who is an electrical engineer or knows electronics? You should have him help you out. This concept is a little tricky, it took me a while to figure out. Before that I was thinking the same as you.
I’m pretty sure the DIO ports on the C RIO are never left floating (at the very least not after they’re initialized), so that doesn’t make much sense. There’s nothing in the datasheet about it, strangely enough, except that there’s a 10K pullup already on it. Maybe that’s not disconnected when it switches to output? That wouldn’t make much sense though.
I’d say test continuity, and then go to voltage mode on your multimeter, and do one lead on ground and the other on the signal. If you get zero, put the first on 5V. If they’re both zero, the pin in floating for whatever reason, if one is zero and the other is 5V, then it’s something in the wiring/arduino.
(Sorry, I went home and slept a bit.) Here’s the Arduino sketch:
int ledPin = 13; // LED connected to digital pin 13
int inPin = 7; // pwm white wire connected to digital pin 7
int val = 0; // variable to store the read value
void setup()
{
pinMode(ledPin, OUTPUT); // sets the digital pin 13 as output
pinMode(inPin, INPUT); // sets the digital pin 7 as input
Serial.begin(9600); //Added this, seems to allow the prints to print
}
void loop()
{
val = digitalRead(inPin); // read the input pin
digitalWrite(ledPin, val); // sets the LED to the button's value
Serial.println(val); // print out the 1 or 0
delay(500); // Added 1/2 second delay just to slow down the prints
}
I took it from Arduino’s DigitalRead() page. I wasn’t going to get fancy until I got something that made sense.
On the LabVIEW side there is code that if (one of 4) buttons are pressed, send a True/False to DIO Out Set (WPI_DigitalOutputSetValue.vi). I hold the button down to test, not momentarily. Currently (with the delay) the print sends “1100000111000011000001100” with or without the button presses, and there is no pattern to the length of the 1 or 0 groups. Without the delay it was all 1s. I also used the built-in LED on 13 to see if it’s on or off.
RoboMaster: I have the book version of that video (that’s how I got my first Arduino). I’m not ashamed to say I’m not electrical-minded, but I know enough to keep me out of too much trouble. For this project originally I used the button setup to control the Arduino switching the LEDs. I’ve wondered about that resistor. This would be a simple test: Put the wire on a breadboard, split it with a resistor to ground, and a wire to Arduino’s pin 7.
I did understand David’s answer (I think I did; hanging around teens I get that a lot), and I was answering more of a programming mode than electrically.
WizenedEE: Maybe in the “robot world” the DIO ports aren’t left floating, but when the wire is jumping into “Arduino world”, would it need it’s own de-floater resistor? I’m guessing at this.
I do have a sensors/electrical mentor; he probably knows every wire on the robot on a first-name basis. He can test the wires to make sure they are what they ought to be.
Sigh. Electricity was so much simpler when I grew up, when power went from + to - and not both ways. 
Okay, back at the ranch… I tried with and without a resistor (10K and 1K – that’s okay? It’s all I had). Signal from DIO connected to the Arduino 7 pin and also to a resistor to Arduino ground. I hope I got that right? I also took the delay out. With a resistor, it’s always zero. Without, the Low/High is
11111100000000
11111100000000
11111100000000
11111100000000
11111111000000
11111111000000
11111111000000
11111111000000
1111111100000000
11111100000000
11111100000000
11111100000000
11111100000000
11111111000000
11111111000000
11111111000000
11111111000000
1111111100000000
11111100000000
11111100000000
11111100000000
11111100000000
11111111000000
11111111000000
11111111000000
11111111000000
1111111100000000
(I manually formatted it – it’s a 128 bit cycle, not that I checked it all.) Pressing the joystick button gets a true/false to the DIO out set vi, but no changes to the pattern.
I think I may know the problem - your grounds are not the same. You’re powering the arduino off of USB right? Try putting a wire from the arduino ground to the robot’s common, and see what happens.
Warning: do not attach robot power to the arduino while the USB cable is connected - you may fry your computer’s USB port
Also, you may want to check with your electronics mentor before trying that… I’m pretty sure it’ll be fine though.
Yes, this is what I was getting at.
I’m puzzled that when you used a resistor it the sensed value was always zero. 10K or 1K seems fine to use. Your code looks fine.
The one thing I noticed was that you split the wire coming from the cRIO DIO into an Arduino Ground and DIO pin. While electrically this will still work, the objective is really to split the Arduino pin to a Ground and a possible power/voltage source (the cRIO DIO wire/pin). That way the Arduino pin either gets electricity “sucked out of it” into the ground, or electricity “pushed into it” from the voltage source. In the second case, the resistor is there to give “preference” to the voltage source pushing electricity in, because electricity follows the path of least resistance (and the voltage source path will only have a low-resistance wire).
I’m not sure what WizenedEE was talking about with the difference in grounds, but he may be on to something. What is trying to be accomplished with your suggested test, WizenedEE?
Yes, the Arduino is still running off the computer’s USB, though I do have a wall plug for it. But, haha, eventually we’ll have to run it off of the robot’s power. We have a 5V stepper thingie, a duplicate of the one the radio-thingie uses. (Can you tell I’m getting out of my area?) This will have to wait until after school tomorrow for the electronics crew to construct.
The differences in grounds, if I may guess: The robot ground is the 12V battery (except the first regional week of Lunacy, when it would be the field, and not in a good way 
). The Arduino ground is the USB port, or the wall power, which is not the same common ground. I don’t know why this difference produces the output I’ve shown.
Just to recap, if the Arduino is powered from the robot, that means it’s grounded to the robot. So if the PWM data wire from the cRIO/sidecar gets split to Arduino pin 7 and also to a resistor and on to an Arduino ground, that ground is also grounded back to the robot, so everything is equal.
Or (thinking further on this) should it be grounded back to the PWM wire back to the sidecar? And if I send 4 or 5 PWM signals to the Arduino, each signal wire gets a separate resistor and back to the PWM.
And just to be sure, the cRIO’s DIO sends a solid HI/LOW down that wire? That output I showed is not what I should be seeing?
Sure, try this and see if it works. That might be related to the “different grounds” suggestion. I don’t think it would hurt.
I would say yes, I can’t see why the signal would be any different for what you are telling it to send out. Now, if you were sending out a PWM signal or some funky square wave or something, that would be different. But you’re not.
So far it isn’t working. 
But we’re testing other possibilities.
Have you checked, with a multimeter, that the sidecar is actually outputting a constant 5V to the right pin?
Try disabling the serial part of your arduino code and just watching the pin 13 LED. Also, take out the wait - a half second is much too long.
Success! :confetti:
DIO White PWM goes to Arduino pin 7, and Arduino ground connects to DIO PWM ground Black. No resistors (any needed?). Next test is 4 DIOs. Solid 1s or 0s when buttons are pressed. Right now Arduino power is either the USB or the wall plug – that gets changed soon.
Yeah, I took out the delay pretty early. The 1/0 list above was with no delay.
Now my lead programmer and I are arguing how to send binary numbers from LabVIEW. His method has 15 numbers – thinking small. My method will get 256 numbers or more. Sigh – the stars are back in alignment, world is back to normal, and programmers arguing about programming.
Thanks guys for your help. Even David – as Sherlock Holmes says “Watson, your wrong guesses sometimes gives me the truth.”
Excellent, great job. May I ask what your methods are? I’m just curious. It seems that with 5 ports you could get 32 outputs, but I’m not sure about 256.