How to daisy chain 50 teensys that use WIZ820io and OSC

Status
Not open for further replies.

nchandol

Member
Hi all,

I would like to be able to control 50 teensys that each is controlling a different BLDC motor controller, using the WIZ820io and OSC.

So far, I have successfully tested the WIZ820io module with the teensy (with or without the PJRC adaptor) and my motor controller.

My question has to do with how would you suggest me to wire the connections for my network. The easiest way I can think off is to use an Ethernet Switch and create a star-like network. However, this will require 50 cables leaving from the same spot.

So, I am interested in finding a way to daisy-chain (mesh-like network) my controllers instead.
Is there a way that I could connect two W5200 modules so that one can be used as input and the other one as output and still maintain my 2-way OSC communication intact?

I have made my own board for the teensy, the WIZ820io and a bunch of buttons, switches and other stuff that are necessary for my controller. (I have attached the schematic).

Schematic.jpgSchematic.jpg

Would it work if I just use another ethernet socket and connect the ethernet inputs of my WIZ820io to that socket? - I am assuming that it doesn't work that way due to the two-way communication and the ips. What would be the way to go for this problem?

Is there someone who has intended to do so? Any info would be really appreciated.

Salutes and Thanks!
 
Last edited:
How are the motor controllers arranged physically, how much distance between them, and what is the layout (shape)? Is it an electrically noisy environment?

Have you considered staying IP / Ethernet based and daisy chaining several smaller (fewer # of ports; less expensive) switches. Something like this:

Net Switch and Motor Controllers.jpg
 
Last edited:
As described by markonian for basic network loads you can get away with using a chain of unmanaged switches and letting them pass the data around until it finds a home. Just make sure you don't form a loop, since that will end poorly. Reason you don't do this in a normal computer network is that it's very poor use of bandwidth because all traffic is seen by all other devices and adds latency. In this case I'm assuming that all these guys are controlled from a single computer anyway with no node to node traffic with no huge need for speed, so dumb switches are fine.

Another option to go full fanout on this would be to have slave devices connected via serial to the network capable units. That leaves you having to come up with some sort of self reporting process for these slave units to their IP gateway so it can onforward the data so the parts cost reduction might easily get eaten by the increased code complexity.

Are you using the Teensy unique MACs or setting them as part of your programing process?
 
Why not use a bus that is suited for daisy chaining, like RS-485? Much cheaper (RS-485 transceiver costs less than €/$1), much less overhead in programming and setting up, robust and just as fast (can easily go up to 1Mbaud, which is comparable to what the Ethernet lib can squeeze out of the Wiznet).
 
Ethernet is the natural choice if using OSC protocol.

Recently I've made substantial improvements to the ethernet library. The version on github now, which will be released in Teensyduino 1.32, can achieve approx 1.2 MByte/sec speed for communication between hosts on the same local ethernet.
 
Hi all

First of all, thank you for your helpful replies it is really appreciated :)

@markonian: Yes, I have considered daisy chaining several smaller switches! However, this is for an art installation and I was thinking maybe there is another way to keep the setup clearer (fewer cables). Ideally, this is the setup I would like to end up with (shown in the pic below). The distances are not very accurate but it gives an idea of the installation. So ideally, there would be a power cable and a signal cable going in the module (motor/driver/power supply assemble), and a signal cable going out to the next module.

System.jpg

This would be eventually installed in a gallery space, and there would be 50 motors with linear actuators attached to them, with coils and power supplies that provide 48V 6A.

@GremlinWrangler Correct, there is no node to node traffic, the drivers are just waiting for an activation signal to start/stop the motors and they report back, speed, position and hall sensor data (the hall sensors are used as limit switches).

The way I am doing my tests so far is by reading the Teensy’s unique mac address with code that I found on the forum and then initiating Ethernet.begin(mac,ip); where the ip is set by the dip switch that I have implemented on the board, as well as the inPort and the outPort for the OSC messages.

@Epyon yes that might be a solution, I should give it a try! However, since I am using OSC as “lingua franca” in most of my projects, I would like to try and see if I can implement it somehow for this project while maintaining a clean installation :)

Another option that I thought off, is maybe trying to use OSC over wifi (using a dedicated wifi network) as described in this tutorial.

@PaulStoffregen thank you for letting me know! :) I will download the newest version immediately to try it.
 
I agree that @Epyon's suggestion of using RS-485 would be lower cost. However, if each Teensy is acting like a repeater I have concerns about worst-case latency of the units near the end of the chain. Please consider making an estimate

WRT cost, @nchandol has not said anything about the cost requirements for this project yet. It already seems to be a significantly costly just considering the 50 x (cost of Motor Controller + Teensy interface). It is not clear how significant the cost of Ethernet vs RS-485 would be for the overall project. @nchandol, can you tell us more about the costs? What is you budget? How is this choice affected by that? Also, consider the value of your time. It is very likely that OSC for Teensy is going to work "off the shelf" as they say - that is with little or no modification. Whereas, daisy-chaining RS-485 repeater nodes is going to require more hardware and software development. Sounds like @Epyon has a lot of experience with RS-485 so it should be interesting to hear what he has to say.
 
Last edited:
cost-wise, the project is quiet flexible and efficiency is of importance. I do get the feeling as well that the OSC is kind of working out of the box but I have never tried the RS-485 in order to be able to express an opinion on efficiency and easy-ness to use.

To give you an idea - I am aiming for a total of 250$ USD or lower for the motor driver and my controller. Given that the motor driver I am using is 109 USD and my custom made board - including the Teensy and WIZ820io is approximately 90$ that adds up already to 200$.

A quick search online gave me a few Ethernet switches for 14-20 dollars with 3-5 ports. So, a “dump” solution might be placing a switch on each motor or very two motors and daisy chain the routers, as initially suggested by @markonian. However, I am wondering if this will introduce huge delays in the communication.

In case it is of interest, I found this module that creates an Ethernet Switch using the PIC32.
I looked for something similar in the ARM world but I was not able to find something.
 
However, I am wondering if this will introduce huge delays in the communication.

I Googled for "network switch latency". I did not find a definitive answer but was led to believe that you can estimate a couple of hundred microseconds for each switch.

Not sure this is possible with your project, but you might consider either:
- one switch per row (7 ports needed) and connect the rows together with one additional switch (12 ports needed)
- one switch per column (12 ports needed) and connect the columns together with one additional switch (7 ports needed)

Note: ports needed for each switch are based upon: 1 chain-in, 1 chain-out, plus the number of Motor Controllers being connected: 5 for row or 10 for column

The main point to the above exercise is to point out that with either of these schemes, the packets go through at most 2 switches. Therefore the latency from your master controller (computer?) to the Teensy can be estimated in the low 100's of microseconds.

Also, Teensy 3.2 and Wiz820io combo will take about 0.5 ms just to receive a packet before it can do anything with it. This is a rough estimate based upon an Artnet project I've been working on. Perhaps you could roughly estimate < 1ms from master controller to begin of Teensy I/O to Motor Controller. Add to this the time it takes for Teensy to control the Motor Controller.

I don't yet know much about OSC. Do you need to send a message to each Motor Controller to update the entire "scene"?

One last question...

efficiency is of importance

What exactly do you mean by efficiency? Efficiency of what?

Very interesting project, btw!
 
I agree that @Epyon's suggestion of using RS-485 would be lower cost. However, if each Teensy is acting like a repeater I have concerns about worst-case latency of the units near the end of the chain. Please consider making an estimate.
RS-485 transceivers are not repeaters. RS-485 is a multi-drop bus, meaning the transceiver listen to anything on the bus and, depending on the protocol, respond when they are spoken to. But this is for a general master-multislave protocol, I have no idea if this would work for OSC.
 
RS-485 transceivers are not repeaters. RS-485 is a multi-drop bus, meaning the transceiver listen to anything on the bus and, depending on the protocol, respond when they are spoken to. But this is for a general master-multislave protocol, I have no idea if this would work for OSC.

I didn't know that. Thanks for the correction.
 
Hi, all :)

@markonian: Yes, I believe the solution I am going for, is the OSC over a few network switches. I found a bunch of 5 port D_Link network switches at Staples.ca for 15 CAD, which is an excellent price. I will test a few of them to see if there are any noticeable delays when running a few of the motor drivers.

However, for the final installation, I am going to follow a pattern similar to your suggestion to avoid having the data going through multiple switches (as much as possible).

The way my software will work is that there would be a trigger (x,y position + energy) from my master software send to all of my motors and then the drivers will respond according to their position on my grid - meaning how far or close they are to that trigger. So essentially, the same signal will be sent to all of them, but each motor will respond according to its position. The position is being defined by their unique IP. If that makes sense. If you are interested I can send you more info. Here is an older iteration of the project. This is the source code that the master software will be based on, where the (x,y) trigger will be given from a tracking system and each intersection on the grid is a motor-driver.

By efficiency, I meant that cost and time spent on programming and wiring the piece should be balanced. Meaning that, if I can spend a few more $ to make it easier (to me) to program and install, then there is the budget for doing so. :)
 
Status
Not open for further replies.
Back
Top