RFC: new project -- simple Propeller based RS-485 / RS-422 interface
Kalo
Posts: 5
http://www.gvgdevelopers.com/concrete/apis/bvw_protocol/bvw_commands_and_responses/
http://www.hardwarebook.info/Sony_9-pin
Hel
I'm fairly new to the Propeller: I've been through a couple of educational exercises and now see an opportunity to get my feet wet in my real world.
In the near future, my employer will be buying and installing Edius hardware (by Grass Valley Group). One of the known issues so far brought to my attention has to do with the RS-485 interface between this hardware and existing playout ports (video servers).
In short, these incoming devices do not automatically send an EJECT command prior to sending a PLAY command whereas our existing process requires this 'extra' step. I find this continued dependence on protocols designed for antiquated equipment to be an added bonus in new equipment installations: thinking of video server playout sequences in terms of tape/cart machine interaction presents all sorts of little gotchas... but I digress.
The circuit I want to build sits in series between the command originating Edius equipment and the destination playout server. It looks at each command as issued and automatically passes everything that is not a PLAY command. Upon receiving a PLAY command, this circuit would first send EJECT downstream before sending the PLAY command. Pretty simple, really.
At this time, a single instance of command insertion is the only purpose of the project. I'm thinking of using the MAX3485 chip as a driver.
I have searched the Obex, but found nothing on point for RS-485 or RS-422 (though I imagine any competent serial communications driver object will do most of the heavy lifting). I've also searched the forums for insight. Though I've found a fair amount of conversation specific to DMX, I've yet to find what I really want: a Sony BVW/Odetics guru in love with the Propeller.
So... any thoughts, opinions and arguments are welcome. Has anyone done this before? Am I reinventing the wheel (and if so, where can I find this... 'wheel'?)? Any thoughts on wiring, programming, and process respectfully considered...
Thanks for your time.
http://www.hardwarebook.info/Sony_9-pin
Hel
I'm fairly new to the Propeller: I've been through a couple of educational exercises and now see an opportunity to get my feet wet in my real world.
In the near future, my employer will be buying and installing Edius hardware (by Grass Valley Group). One of the known issues so far brought to my attention has to do with the RS-485 interface between this hardware and existing playout ports (video servers).
In short, these incoming devices do not automatically send an EJECT command prior to sending a PLAY command whereas our existing process requires this 'extra' step. I find this continued dependence on protocols designed for antiquated equipment to be an added bonus in new equipment installations: thinking of video server playout sequences in terms of tape/cart machine interaction presents all sorts of little gotchas... but I digress.
The circuit I want to build sits in series between the command originating Edius equipment and the destination playout server. It looks at each command as issued and automatically passes everything that is not a PLAY command. Upon receiving a PLAY command, this circuit would first send EJECT downstream before sending the PLAY command. Pretty simple, really.
At this time, a single instance of command insertion is the only purpose of the project. I'm thinking of using the MAX3485 chip as a driver.
I have searched the Obex, but found nothing on point for RS-485 or RS-422 (though I imagine any competent serial communications driver object will do most of the heavy lifting). I've also searched the forums for insight. Though I've found a fair amount of conversation specific to DMX, I've yet to find what I really want: a Sony BVW/Odetics guru in love with the Propeller.
So... any thoughts, opinions and arguments are welcome. Has anyone done this before? Am I reinventing the wheel (and if so, where can I find this... 'wheel'?)? Any thoughts on wiring, programming, and process respectfully considered...
Thanks for your time.
Comments
There's only one concern: Do you have more than one transmitter on the same pair? If this is the case then you have to enable the transmitter before sending data out of the device and then disable it (to make the line available for other devices) when done. I've attached a really simple half-duplex driver for RS-485 comms where there can be mutliple transmitters on the line. The TX code take care of enabling the chip, sending the bytes in the buffer, then shutting down the device to free the line. I think you'll agree that it's fairly simple code, and I've duplicated the methods from FullDuplexSerial to make things as easy as possible.
I am interested in Modbus for a PLC project using a propeller for some external signal conditioning. Any good tutorials on the mod bus protocol??
Steve
These are the documents I referenced for my work:
-- http://www.modbus.org/docs/Modbus_over_serial_line_V1.pdf
-- http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf
Any additional questions on MODBUS should be in a different thread as that is not the topic of this one.
Specifically, I am trying to run two instances of the object (my board has two drivers). Everything works perfectly EXCEPT the two instances of the object are interfering with each other and I cannot yet figure out why.
If I set up the first instance and declare an Rx and Tx pin, it works great.
However, if I set up the second instance (with different pins), the program hangs.
If I then comment out the first instance, the (old) second instance runs perfectly also.
If I set up the first instance and pass -1 as the Rx pin and the second instance with -1 on the Tx pin (or vice-versa), it works perfectly as a pass-through.
Is there any chance you could please revisit it again and see if there is something I am missing?
Your problems with two instances may be due to needing to use half-duplex software.
Sure RS-485 can work over one twisted pair, but having two twisted pair to achieve full-duplex really is nice. I have a USB to RS-422/RS-485 adapter that allows me to communicate with my Propeller (usually in Forth) over long wire distances. I added a third twisted pair and I can actually download binaries to the Propeller from great distances.
About the only thing better is fiber optic. It can avoid interruptions for lightning.
FTDI makes a full USB to RS485/RS422 dongle that can't be beat for plugging into the computer end. You just have to mount a DB9 or RJ45 socket on the end of it to be ready to go.
http://www.ftdichip.com/Products/Cables/USBRS422.htm
All of the pieces work great except trying to get the two ports working simultaneously. I've been trying to work through why it won't work for awhile now. If I can't get any advice in this thread I will attempt to rewrite one of the 4-port FDS objects to work with the 485 chip (basically just adding R/W pin control), which is what I was in the middle of attempting when I stumbled across this thread (and object).
Thanks huge for your response :-)
ETA- In fact, the entire system works well, but only in one direction- I can get the byte from the pendant, process it, and then send it to the controller, and it works great.
How would I do this? Ok, my personal approach, which may well be different to other approaches, would be to do this in stages.
The protocol is 38400 baud and RS422. The propeller will be a great solution.
1) Start with RS232. You can get a USB to RS232 converter for under $2 eg http://www.ebay.com.au/itm/USB-to-RS232-Serial-Port-9-Pin-DB9-Cable-Serial-COM-Port-Adapter-Convertor-AU-/390896764178?pt=AU_CablesConnectors&hash=item5b03434512
2) Download a terminal program eg PuTTY.
3) Get a D9 female socket, join pins 2 and 3, plug into the USB to RS232 cable, set the baud rate to 38400, run PuTTY in Serial mode, type a character on the keyboard and it should appear on the screen. Unplug the female D9 loopback plug and the characters should no longer appear. This simple loopback test can be very handy to debug and exclude certain faults.
4) Convert RS232 to RS422. There are three RS232 lines, Gnd, Tx and Rx. Tx gets turned into two wires on the Sony 9 pin protocol, and Rx also to two wires. The differential voltage for RS422 allows the signal to go further.
5) Get a RS232 to TTL converter (or several) for $1.30 eg http://www.ebay.com.au/itm/MAX3232-RS232-Serial-Port-To-TTL-Converter-Module-DB9-Connector-With-Cable-TR-/141468836798?pt=AU_Gadgets&hash=item20f03323be or alternately, go USB to TTL directly for $1 http://www.ebay.com.au/itm/1pcs-PL2303-PL2303HX-USB-To-RS232-TTL-Auto-Converter-Adapter-STC-Module-Sales-I-/281342792197?pt=AU_Gadgets&hash=item4181565205 or alternatively, go USB to RS485 directly for $5 http://www.ebay.com.au/itm/USB-to-485-Module-FT232-Chip-USB-to-TTL-RS485-Double-Function-Double-Protection-/291314600972?pt=AU_B_I_Electrical_Test_Equipment&hash=item43d3b40c0c
Looking at the Sony protocol, you will need two RS485 (RS422) modules, one for each direction.
Then there is the Propeller interface. There are four different hardware protocols here, and I guess one has to think about which one to standardise on:
1) TTL 5V (Arduino uses this a lot)
2) TTL 3.3V (Propeller uses this)
3) RS232
4) RS485
Where it gets complicated is if you are debugging and experimenting and constantly plugging and unplugging things. My experience is that sometimes wires touch where they shouldn't and 5V from RS485 finds its way into a 3V propeller etc. Maybe that is just me being a klutz! But some time ago, when I started interfacing Arduino (5V) and Propeller (3V) I decided that I would pick one of these and not change it. I chose RS232 with no handshaking, essentially a 3 wire protocol. So my propeller router has four D9 RS232 plugs on it, and I find I can mix and match quickly to Arduino, to radio RS232 modules, and to a PC and rewire things in a few seconds and never have to worry about shorted pins or pins connected the wrong way, as the 3 wire RS232 solution can handle the wires being connected in any wrong combination with nothing being zapped. So if I want to get a longer connection by adding RS485 to the network, I would get a RS232 to RS485 module. For 38400 baud, RS232 would start to degrade after ?? 5 to 10 metres. So I tend to use 3 wire RS232 for short links, RS485 for medium length (over 10 metres but in the same building) and radio modules for longer links.
Then there is the question of a multidrop bus vs using some sort of serial router. The common solution is to use RS485 on a multidrop bus, but you need a protocol that can handle two devices that talk at the same time, and software protocols for handling this data clash and ways to resend packets. Also if many devices need to communicate at once, the bus can get clogged with data. The other solution, which the Propeller has made possible for only a few dollars, is a true serial router. Because the propeller has multiple cogs, you can dedicate a cog to each serial line, and collect bytes from multiple connections at once and store and buffer them. So with a 4 port propeller router, data comes in port 2 and then it is sent out of ports 1, 3 and 4. If data comes in ports 1 and 2 at the same time, buffer both, then send the data from port 1 out to port 2,3,4, then send the data from port 2 out of 1, 3 and 4. From a hardware perspective, such a router could be RS232, but it could also easily have 4 of the Sony protocol ports, with 4 D9 plugs. Such a box could be quite handy actually!
Then there is the gender problem - do you have male D9 on boxes and cables are female to female, or do you have cables going male to female. RS232 says that for a female socket, data always comes out of the same pin, so to make a female to female cable, you have to cross over pins 2 and 3. That is simpler to understand for RS232, if you have RS485 you have to cross over more pins. It is probably why many RS422/485 systems give you screw connectors rather than a plug. So RS232 is simpler in this respect because you can make up a series of universal cables - male to male with pin 2 and 3 crossover, female to female with 2 and 3 crossover, and male to female straight through. Then you don't have to think about whether a pin is a Tx or an Rx when plugging things together in different ways.
But I know others would do things differently. In fact, looking at that D9 Sony protocol, that is actually quite a nice protocol to pick for networking. D9 plug but can go longer distances.
Conversely, I can write data back to the FIRST instance (the pendant) and the program will not hang. I have tried various schemes of clearing the buffers etc to get it to work to no avail.
So the bottom line is that I can declare everything as I like and everything works great, including writing back to the same port where the data came from originally, until I attempt to write anything at all to the second port, and then it hangs.
I know it's not a hardware issue because I can rewrite it to plug the pendant into the controller port and the problem is mirrored- it works great until I write to the 'other' port ('other' being the one opposite to the one that I am getting pendant data from).
And oh- Jon's object is bone stock- I didn't so much as add a comment to it.
Can you post your code and an image of your hardware?
Dr. Acula seems to be addressing the original poster's project. Be very careful to understand whether you really need half-duplex or full-duplex. A lot of advertisers clump RS-485 an RS-422 together as their devices can do both (with proper configuration).
OBEX provides a full-duplex object that will work with up to 4 devices. That may be the easier way to go. My own feelings are that once needs to pull wire to a project at some distance, the actual cost of two twisted pairs or merely one is nominal, while the full duplex avoids having to code for read/write control.
The challenge of RS-485 is the programing of that read/write flow control. It introduces the need for polling code and delays. One end has to default to listening until something is received. The other end has to wait for responses before sending again, or collisions occur.
CANbus has been developed just to manage multiple drops on one RS-485, but it is far from simple. (You seem to have paired devices that lend themselves to full-duplex.) RS-422 can work seamlessly with paired devices, and you can easily have one, two, three, or four working with one Propeller.
As mentioned before, the code is simply asynchronous serial (the same as provided for RS-232 full duplex without hardware flow control).
++++++++
And yes, you need to post code if you want input to resolve the RS-485 solution you first mentioned.
I have used plain telephone wire (not twisted pair) up to 100' without problems as long as the baud rate is not too high. I can get 3Mbaud over twisted pair over 100' of wire, though I rarely go above 115Kbaud.
I have used it as a serial data sniffer, port concentrator, port router, protocol translator, and some combinations of them. Even use it for projects that only need a single serial connection since it only needs a single cog.
I'm real sorry for bothering everyone, and Jon, I will pay it forward. Thanks to all of you for your time :-) I love this place :-)
Just for the record, I'll post a demo of using fullDuplexSerial4port for RS485. This is for a half-duplex 8-pin chip like the LT1785 or LT2862. This is the unmodified 4-port driver, so it is necessary to open the RS485 port in open mode with no echo. The pullup resistor on the data line is necessary. Direction control is handled in Spin, not by the pasm.
I recommend one of the 1/8 load fail-safe 485 chips such as the SN65HVD3082E rather as they won't receive data if the line is shorted or open. Line termination resistance is only needed at either end of a line, especially if it's long and should be 120 ohms. Many of the earlier chips required line biasing as well to prevent false signals due to line open (all chips in receive) or line short. So the failsafe chips don't require any extra resistors on the line.
@Tracy: Why do you need the 10k pullup? On some chips the rd trisates but this will only happen when you are transmitting with dir high so it's inconsequential and since dir is pulled low then it won't try to grab the line during boot etc. These chips also accept TTL high (2V) so they don't need extra pullup to 5V which might be a reason, although I've never had to.
I like the LT parts, which also have the failsafe, and they extend common mode range to +/-25V and have other protections that may make them worth the extra buck.
So that's really to do with the driver then but then again I have my own specialized versions for all kinds of commercial stuff. But the good thing about RS485 is that it also simplifies the driver in that it doesn't have to try and full-duplex thus limiting the maximum baud rate and normally you only need the one RS485 port for multidrop. So if the obex doesn't have a decent RS485 driver I may have to spruce one up for it. IIRC quite a few of my drivers handle all the bus idle and 8 or 9 bit modes, pacing, and addressing and some neat peer-to-peer networking so that they don't require a master. There's also broadcast and group addressing that takes care of sending data to many nodes and the equivalent of DHCP.
One mode of addressing and collision detection I use is to send the 9-bit mode address and wait for a confirmation echo which indicates acceptance and readiness after which it's considered point-to-point until a a bus time-out or a 9-bit control is sent so other nodes can jump in.
Peter, you're tantalizing us with all your advanced features. I for one would like see how you've implemented it.
Glad you got things sorted!
I think one of the first microprocessor projects I tackled was done in machine code (yep) and I wrote bit-banged multi-drop communications drivers over coax cable. When I did POS terminals I migrated from there to simple unbalanced full-duplex single master and then to RS485. The 9-bit mode that was available on 8051s was particularly useful for all kinds of slave devices but even uarts that are limited to 8-bit mode can still utilize 9-bit mode as long as they report frame errors. So a frame error indicates the 9th bit was a zero which in this case we would interpret as an address or command, but no frame error would be raw data, simple! Anyway with the Prop we aren't limited at all and so there is no problem at all in implementing 9-bit or whatever schemes we like.
As for the object as I said I will have to spruce up one as it will probably be a general-purpose hybrid of the different ones I use already. Can't believe that RS485 hasn't been addressed in the obex yet but we will soon rectify that. I will pst a Spin interface version along with a Tachyon version as the PASM code will be pretty much identical anyway. The general peer-to-peer or master access scheme is simply to CONNECT and other devices are in LISTEN mode much like TCP/IP networking. Maybe I should introduce port sockets as they are pretty useful for networking in general and you know what, that means we could leverage FTP and other protocols that I have running in Tachyon, now that would be neat.
I can attest to this.
Jon's object (two instances of it) is/are running perfectly and hasn't stumbled once since last night.
Jon, I really meant it when I said I would pay it forward and I did a couple small things to help others today (it is cold and windy here and I pumped gas for two little old ladies if you are wondering) but I normally do things like that anyway.
I really do appreciate all of the help from all of you. Thank you all again :-)
-bryan