WildStang 2015 Beta Testing blog

[billbo911]

Originally Posted by Mark McLeod

Did you meant this version?

Yep, that'll do it! How I missed that, I am not sure. Thanks.

Originally Posted by SteveGarward

Thanks Mark, beat me to it.

The only downside to this board is the additional cost of empty space. Probably worth it for security.

That extra space can be utilized for many things, including security. You may find a need to add additional custom circuitry, this space would allow for that. The security alone will be worth every extra penny spent!

[SteveGarward]

Originally Posted by billbo911

That extra space can be utilized for many things, including security. You may find a need to add additional custom circuitry, this space would allow for that. The security alone will be worth every extra penny spent!

After yesterday's update on the forums here, be careful what custom circuitry you add. Looks like most things would classify it as an active device.

[Greg McKaskle]

Out of curiosity, just how much does security cost? Or do you have price estimates for the different versions?

Greg McKaskle

[SteveGarward]

The board that spans the roboRIO to reach the screw holes comes to about 3" x 3". We were going to use oshpark.com again as we have had good results from them in the past. They charge $5/sq in for 3 copies, which comes to about $15 per board. Add header pins, and it's not much more than that, depending on how you buy.

The board could be made narrower - we were sticking with the footprint of our other board.

My only issue is that for a passive board with only breakout pins, there is a lot of empty space.

The mini version is a total of around 6sq in, so about $30 for 3. So I guess security costs about $5 per board.

[Greg McKaskle]

Good to know. Thanks.

Greg McKaskle

[Michael Blake]

Hello... thanks for publishing such an informative blog!

3481 is one of the Texas Beta Teams. Have you guys seen this new REV board, it looks like it does everything you guys are talking about and will be available soon through AndyMark?

https://www.facebook.com/REVRobotics

--Michael Blake

[SteveGarward]

Here's an update on our original MXP board design, and what we've decided to do with it. Short version, we not aiming to get it approved by FIRST at this point. Too many other fun projects and things going on for us to be able to work out inventory and vendors etc.

[billbo911]

I noticed while reading this document that the RoboRio connects to a Host computer via USB. (Pg. 5)

Does this mean that the RoboRio is programmed via USB and not ethernet?
Can we still "Run" code before building it and the deploying it? (I certainly hope so!)
Can we still "Run" and deploy code wirelessly? (Again, I hope so! I've seen one too many laptops go flying.)

(Sorry, I haven't seen this mentioned yet or I just haven't looked hard enough.)

[Joe Ross]

Originally Posted by billbo911

I noticed while reading this document that the RoboRio connects to a Host computer via USB. (Pg. 5)

The USB is an additional network interface, in addition to ethernet and wireless. You can program over any of them. I think your questions are LabVIEW specific. The LabVIEW process is exactly like before with the exception that reboots are no longer necessary when running code as startup.

[Mark McLeod]

Originally Posted by billbo911

I noticed while reading this document that the RoboRio connects to a Host computer via USB. (Pg. 5)

Does this mean that the RoboRio is programmed via USB and not ethernet?
Can we still "Run" code before building it and the deploying it? (I certainly hope so!)
Can we still "Run" and deploy code wirelessly? (Again, I hope so! I've seen one too many laptops go flying.)

(Sorry, I haven't seen this mentioned yet or I just haven't looked hard enough.)

Program via USB or Ethernet or wirelessly.
The USB is recommended for imaging the roboRIO, but once it's imaged, either connection method will work.

Yes, we can still "run" debug mode before downloading the code permanently.

Yes, we can do all that wireless, via Ethernet, or via USB.

[SteveGarward]

We have deployed code via USB, Ethernet and over WiFi. So far, all is well.

[Greg McKaskle]

Just to pile on. The roboRIO identifies itself to USB such that an interface driver is loaded on Windows. The driver will bridge ethernet over USB, allowing all of the other programming tools, from cmd line to Eclipse or LV IDEs to work transparently using UDP, TCP, ICMP, HTTP, or anything that works over ethernet.

The USB interface will always be on the 172.22.11.xx subnet, just in case you were wondering.

Greg McKaskle

[SteveGarward]

Greg: Knowing that it's using mDNS, is there a defined/standard set of IPs that it tries to assign to the common parts (eg, roboRIO, driverstation)? I guess really only the roboRIO is common now..

This relates to... We were looking at having an offboard unit connected via ethernet for logging direct to SD card, among other things. If the offboard unit is listening for logging over UDP, we need to know its IP address. Ultimately, we need to know how likely it is to get a new address. We can always set it in the bridge as a defined IP, but don't want to cause any conflicts.

If that makes no sense, let me know. (It's been a long day..)

[billbo911]

Thanks everyone for the replies!
Wow, it sounds like a lot of the connection and deployment issues may be addressed and resolved. Awesome!

Originally Posted by Joe Ross

... I think your questions are LabVIEW specific. The LabVIEW process is exactly like before with the exception that reboots are no longer necessary when running code as startup.

Joe,
You are absolutely correct. I hadn't considered, or realized, I was looking at this from just one point of view. We have always used LV up until this year. We are now moving to Java with the help of a new mentor who does programming for Oracle.

[Joe Ross]

Originally Posted by billbo911

You are absolutely correct. I hadn't considered, or realized, I was looking at this from just one point of view. We have always used LV up until this year. We are now moving to Java with the help of a new mentor who does programming for Oracle.

C++ and Java don't have the distinction run and build/run as startup. This is true for the cRIO and the roboRIO. However, a build does not take very long and occurs as part of the deploy process. New for the roboRIO is that a reboot is not necessary for a C++ or Java deploy.