Comments on RepRap: Blog: RS485 Circuit = Success

Hey, Zach:Great work! I like the idea of RS-485.An...

2009-02-05T23:02:00.000Z

Hey, Zach:

Great work! I like the idea of RS-485.

Any chance of posting the sketches used on the arduino boards for testing?

For a project I'm working on RS-485 via arduino would be handy.

Keep the faith.

Andrew

Forgot to say this:- needs no soldering- frees up ...

2008-10-20T16:27:00.000+01:00

Forgot to say this:
- needs no soldering
- frees up pins
- heavily tested in the field.
- certainly compatible with the nanotec steppers we already recommend on the wiki, but also with many more.
- Even lower resolution steppers will become usable when microstepping with 1/16th.

Below is a good example of a dual microstepping bo...

2008-10-20T16:23:00.000+01:00

Below is a good example of a dual microstepping board that can be controlled by RS-485. It also confirms that RS-485 is a proven protocol for these types of applications.

http://en.nanotec.com/steppermotor_positioningcontroller_smci21.html

It is a bit expensive, but not even much more expensive than two Stepper Motor Driver v1.1 Kits (50% more expensive). It is plug and play, uses up to 1/16th microstepping (and chopper driving) capability and is controlled via RS-485 already! Besides the extra resoltion, driving it sinusoidal will reduce resonance by a lot.

I would really like to see some comparison (protoc...

2008-10-14T16:42:00.000+01:00

I would really like to see some comparison (protocol-wise) between:
* modbus
* profibus
* compobus (omron's preferred field-bus)
* can
* devicenet
* our SNAP solution

Why we prefer modbus over our already implemented and tried SNAP?

If modbus is better, is it the best available solution?

Is a standard (and complicated) protocol is better solution over a custom one? (I mean a standard solution want to solve all available problem in the automatation area. So it is complicated and needs many effort to implement it properly)

I would like really see some comparison between field busses, and if we choose one standard protocol I would like really see some technical reasons for it.

peter: thanks for the modbus suggestion! i was n...

2008-10-13T21:50:00.000+01:00

peter: thanks for the modbus suggestion! i was not involved in the original protocol implementation/specification but after looking at the modbus stuff, it looks like a very attractive solution.

Dave asked:> If so, will you use SNAP or another a...

2008-10-13T12:39:00.000+01:00

Dave asked:
> If so, will you use SNAP or another approach to share the medium?

Could we go with a more common protocol, such as modbus, this time?

Ah, the old RS485 vs CAN argument. I think you we...

2008-10-13T04:46:00.000+01:00

Ah, the old RS485 vs CAN argument. I think you went the right way for the current design. You'd have to switch to a controller with an embedded CAN controller to reach price parity, but that is a rare Atmel chip. I just don't like being forced on some chips to run a specific baud rate to get a stable async network connection.

CAN does bundle up all the low level timing and maintenance issues into a single hardware controller, but if CAN does become an option (I see it more from the PIC-Alternative branch of research) I'd expect it to be added in a shield or as a standalone bridge module. Frankly, if boards needed an external controller, might as well use an ENCJ60 and wire everything up over true Ethernet.

larry,thanks for that excellent tip!luckily for us...

2008-10-12T18:32:00.000+01:00

larry,

thanks for that excellent tip!

luckily for us we are using the exact chip he specifies, and we are also giving full control over both enable lines to the sanguino which means we can easily implement his final suggestion.

i'll certainly look back at this pdf when it comes time to implement the comms.

cheers!

Zach at al,Are the noise problems so severe that t...

2008-10-12T17:17:00.000+01:00

Zach at al,

Are the noise problems so severe that they can't be dealt with by shielding, star grounding, and a few ferrite beads?

RS485 is useful, but can get tricky, especially if used as a multi-drop network (more than two devices communicating -- probably our case eventually.) Here is a link to a good article about one RS485 pitfall, and how to avoid it.

http://www.rmbconsulting.us/Publications/TxEnable.pdf

This is by my former colleague, Nigel Jones, a seriously sharp guy.

HTH,

Larry Pfeffer
ursine at gmail d0t c0m

thanks guys!leav: thanks. i'm certainly no expert...

2008-10-12T17:01:00.000+01:00

thanks guys!

leav: thanks. i'm certainly no expert: i just know enough to be dangerous. luckily there are others on the team that did the real work of finding the proper chip, etc. that allowed me to do this. other than that, its just lots of reading: theres a ton of information on the web, and i learned by reading, doing, and playing.

dave: thanks as well. =) ideally we can have a hybrid world with a common interface that users can use to add compatible devices to. i'm an AVR fan myself, but i'm all for compatibility. cheers! i think the idea is to have multiple devices on one RS485 line. we'll probably have to have one 'master' and the rest be 'slave' devices or some such. first i want to get the physical/electrical layer right. then its all software =)

jon: i believe nophead looked into CAN, but it seems fairly expensive (~$10/chip vs. $0.80/chip) i could be wrong though.

My first job was for a company producing test gear...

2008-10-12T14:46:00.000+01:00

My first job was for a company producing test gear for car factories. At the time, the ECUs in cars (ABS, steering, motor control, etc.) all used RS485 - but were slowly on the path to migrating to CAN. This solved their problem of wiring frames becoming ever more complex as the number of ECUs multiplied.

It's probably too complex a system for RepRap, but the problem space does strike me as similar. Due to the heavy usage in automotive applications, there are also very many parts capable of CAN. It might be worth a look.

Hey, Zach:Great work! I like the idea of RS-485. I...

2008-10-12T13:50:00.000+01:00

Hey, Zach:

Great work! I like the idea of RS-485.

I'm still on the PIC bandwagon over here. I like RS-485 because I suspect that there may be a world in which sanguino/argudino and pics co-exist.

I love my pics for some applications-- example 1 is motor control. you just cannot beat an 18f4431 for that application-- is has hardware quadrature encoder readers, and pwm generators.

great thing about rs-485 is that just about every uC has one or two UARTS in it, and a simple level converter allows RS 485 with no trouble.

You were talking about multiple devices-- are you going to allow multiple devices to share the rs-485 bus? If so, will you use SNAP or another approach to share the medium?

P.S.Zach, Amzing work!how do you become so awesome...

2008-10-12T09:47:00.000+01:00

P.S.

Zach, Amzing work!
how do you become so awesome in electronics?!?

(seriously where did you learn this stuff?)

I'm no RepRap expert but I doubt there is any sing...

2008-10-12T09:13:00.000+01:00

I'm no RepRap expert but I doubt there is any single cable longer than 2m in there :)

-Leav

Hello,great article on RS485. I worked on lift con...

2008-10-12T08:41:00.000+01:00

Hello,
great article on RS485. I worked on lift controllers and we used RS485 for group controllers, communication with the car and Remote monitoring.
There are a few points you must be aware of:
-the speed of the network is dependent on the distance (rule of thumb 9600bps - 500m).
-a termination (active/passive) network is needed if distance >50m and speeds >9600bps.
-you must have a common ground connecting both interfaces.