How to connect multiple Props to a PC?
Akkarin
Posts: 43
Hi there,
I'm using the Props 80MHz counter on a custom board for a capacitive sensor system. I managed to use one cog to continously take measurements and set a pin if some threshold value is exceeded. For maintenance purposes I use another Cog to listen to the COM port and wait for user commands like e.g. report the last sensor value to the terminal.
For an industrial project, I need to connect up to 10 or more of these sensor boards to a PC. I'd like to be able to select a certain Prop/Sensor and ask it for several values, like last sensor value or even send it a command to set a new threshold, then I select another board and so on. Apparently I can not connect every single board via USB to the PC. But how could I accomplish this?
My first idea was to use three Mux for RX, TX and RST(DTR). I wrote a LabView program which addresses the Mux and also is able to communicate to the Prop over the Com port. The problem is: once I switch the serial lines (TX, Rx, RST/DTR) from one Prop board to another I have to close and reopen the Com port since I only get gibberish on the serial lines. But closing and reoping the Com port causes the Prop I switch to to reboot since there occurs a high pulse on the DTR line. Apart from the reboot this works fine, but unfortunately rebooting is not an option, I need the boards to keep on taking measurements all the time.
Ah I should say that I use the same circuit as on the Prop Plug with an FT232. I.e. DTR is followed by a cap and resistor and a NPN small signal transistor whose collector is connected to the Props RST pin.
I'm sure there is a better way to connect multiple Prop boards to one PC and I'm awaiting your input
I'm using the Props 80MHz counter on a custom board for a capacitive sensor system. I managed to use one cog to continously take measurements and set a pin if some threshold value is exceeded. For maintenance purposes I use another Cog to listen to the COM port and wait for user commands like e.g. report the last sensor value to the terminal.
For an industrial project, I need to connect up to 10 or more of these sensor boards to a PC. I'd like to be able to select a certain Prop/Sensor and ask it for several values, like last sensor value or even send it a command to set a new threshold, then I select another board and so on. Apparently I can not connect every single board via USB to the PC. But how could I accomplish this?
My first idea was to use three Mux for RX, TX and RST(DTR). I wrote a LabView program which addresses the Mux and also is able to communicate to the Prop over the Com port. The problem is: once I switch the serial lines (TX, Rx, RST/DTR) from one Prop board to another I have to close and reopen the Com port since I only get gibberish on the serial lines. But closing and reoping the Com port causes the Prop I switch to to reboot since there occurs a high pulse on the DTR line. Apart from the reboot this works fine, but unfortunately rebooting is not an option, I need the boards to keep on taking measurements all the time.
Ah I should say that I use the same circuit as on the Prop Plug with an FT232. I.e. DTR is followed by a cap and resistor and a NPN small signal transistor whose collector is connected to the Props RST pin.
I'm sure there is a better way to connect multiple Prop boards to one PC and I'm awaiting your input
Comments
Looks like you've already implemented your prop for industrial use. That's great! There are quite a number of members that have already accomplished such setup & I'm sure they will chip in.
I have something similar in one of my projects. Basically, I have a master prop that communicates with other client props. And, I use Beau's high-speed multi-prop object to collect the data from all other clients. Once the token is back to master prop, it will dump the data to uSD and start the data collection again. The PC will then read the data from the uSD.
It is possible to "party line" P31 (RX) and the reset pin, to load up the propellers in parallel. Each propeller needs to use a pin or more to set its 'address' on the line. There is a 'Propeller Loader' object by Chip Gracey in the obex (here).
There is also a 4 port version of the FT232R - see the FT4232H. This would give you access to 4 props over 1 usb port.
Finally consider a master Prop - it could fan out to ~14 slave props using a commoned reset.
thanks for the quick replies.
I will look into your suggestions right now.
One question to the master prop though: does the master prop only collect data from the salves or is it also possible to send data back to the slaves like e.g. to set a new threshold value?
One aspect I like about my Mux approach is that I can reprogram a single board if it is necessary for any reason. Propably this is possible with your suggestins, too, I have to look into them now.
Propforth MultiChannel Synchronous Serial (MCS) allows connecting multiple props at the cost of one cog each on the master prop and on the slave prop. There is no limit on the number of props. The interface on the master "plugs in" to the interface on the slave, and gives access to all the slave cog just as if it were on the master. We can also "plug in" to the interface on a sub slave the same way. MCS includes protocol, so we just drop a character in our end and it pops out the other end. There may be a slight delay from the master to the N-th prop, but we haven't measured it and haven't noticed it yet. Its like a couple clocks per prop so its pretty small.
The Propforth MCS is also compatible with Go Channels from the Go Language. This allows opening multiple terminal sessions on the PC to multiple cogs on the Prop array. At the moment we have it configured to support 32 channel simultaneously over a single physical serial cable connection, but you can change it how ever you need. It a bit slow for now, only around 40 characters per second under windows but does around 3000 characters per second under linux
http://code.google.com/p/propforth/wiki/PF521BETAthroughput
but this is due to running the synchronous serial (MCS) over the asynchronous USB virtual serial port connection at only 230400 baud. When we put it on 100 megabit Ethernet (using spinneret/ wiznet5100) it should go a bit faster. My tests used four of up to 32 channels.
All this is written in forth with critical sections optimized in assembler, so it should be fairly straightforward to implement in the language of your choice if forth is not acceptable.
Edit: the results listed are from the v5.2.1 BETA. We are finishing up the v5.3 public release now, it should be ready in a short while. We are just cleaning up the methods for the built in test automation that's coming out in this release. The kernel itself is rock stable and the regression automation is completely stable, we're just figuring out how to deal with stuff that always changes when correct, like time stamps and undefined pin states. We think we got it nailed, so its shouldn't be too long now.
@T Chap: Distance will be about 10 meters. You think this will be a problem? I just had a quick look in the datasheet of the MAX3430 and it looks very promising. I guess I'll order some and have a try
Right now I'm working with Beau's HsP2P. I just set up two Props according to the example and playing around with Buffer, Command and Offset.
Don't let that stop you from giving it a look. Forth is easier than BASIC, the difference being its faster (almost as fast as assembler with optimization at bottle necks) and you can do everything assembler can do. If you can work a calculator, you can program in forth. A bunch of the stuff you need is already implemented, you might be able to use some of it. Cheers!
\http://forums.parallax.com/showthread.php?127983-55-Parallax-Propeller-s-Parallells-Processing-of-Permanent-Perturbations.
I couldn't imagine to get so many good quality responses in such a short time. THANKS
Now I guess I need a few days to digest it all and decide which way to go
Xbee or Wifly come to mind.
There is a very nice free pdf book about Xbee on the parallax website.
Massimo
I'll try to dig up the files and post them later, I 'think' that with this configuration each Propeller only loses two I/O pins for communication.
What is the distance Board-to-board ?
You can simply OR-tie all the reply TXD's and all receive RXD's and implement a RS485-like tri-state enable on the TXD pins (use 120 ohm esd/edge resistors), and a common pullup to give a defined idle state
This means Prop replies default all OFF, and only the addressed Board replies, within a strictly defined time slot.
If distance gets too great, use a proper RS485, or even a CAN transceiver. (CAN HW layer does not need Drive enable)
To simplify timing, you can use a full duplex wiring, which makes turn around timing less critical, and you then need 14 pin
parts, (or 2 8 pin parts) as they have a Driver Enable, all receivers run on all time.
With pure RS485, hand over timing is important, and debug is not as easy.
You can run 'CAN' duplex with a device like TJA1048 (SO14)
Another approach is a ring, as others have mentioned.
We've done this using what I call a twisted ring, with no address overhead. Suits simple, identical slaves.
Here you use the 9th bit as an edge flag, and when any node sees a fall in 9th bit, it removes the next X bytes, replaces with replies, and sets the 9th bit in each reply. In all other cases, it simply exactly repeats the data.
This means the first device gets/sends the first flagged block, and it moves the edge flag, so the next device takes the next block, and so on.
Address is entirely by position in the ring, and it is very simple and fast. PC can determine the ring size, by either byte-counting, or by having inherent spare bytes, and sense of the 9th bit state.
Byte numbering is also Automatic, as is handshake control, as every byte coming in, replaces a byte sent by the PC
Handling the 9th bit is not quite as easy as it was, with the new USB RS232 devices, but the nimble stuff is done in the slaves, and if you arrange the bit so it looks like an extra stop bit to the not-so-clever PC, you simplify things.
And one cog on each propeller?
I jut got the quickstart and HC06 ($3.32 ebay) on four AA batteries to talk to the android phone from two houses down. Works fine at 230400 baud, other folks have gone higher.
Sounds like your current solution would work fine if DTR was only hooked up when you wanted to re-program a chip. Since it also sounds like the mux is near the operator station, how about adding a momentary switch inline with DTR and a pull down resistor after the switch? That way the com port will only reset the propeller if you hold down the button. (label it "program enable" or something?)
Lawson
There is a slight change to the file that addresses if the USB is connected to a PC or not. This prevents any unwanted resets. The newest file can be downloaded here or from the above link.
High Speed Multi-Prop to Prop Communication_v2.zip
@prof_braino - "And one cog on each propeller?" - basically yes, after each packet transmission or reception the cog terminates and is re-started on the next transmission/reception. So at any given time the TX/RX is only using one COG outside of the main running COG.
just a quick update before I read all the new posts properly:
I was playing around with Beau's HsP2P Version 1 with two Props and it works fine. I also used PropellerLoader to program the Client Prop. So I think I will go for that in a round robin configuration. But I want to try it with a third Prop first, though. I like the idea that I can download the program to all Clients at the same time. So I will try Version 2, too, thanks Beau!
I also ordered some RS485 tranceivers and a FT232 eval board which should arrive today. I'd just like to try different approaches to see which one suits best for my needs.
it took a bit longer due to other projects, but now I got the round robin configuration up and running with two clients and one master which also loads the clients with the same programme.
I use the command field to tell the clients on which position to write in the Buffer. I'm sure this is what 'Offset' is for, but I couldn't get it to work.
pub SerialComm | value,packet,com repeat packet:=hsRX.RX(RX_Pin,@Buffer) ' Receive Data from External Propeller com:=packet&$F ' mask command field { %ssssssssssssss_aaaaaaaaaaaaaa_cccc       └ Packet Size┘ └ Dest Offset┘ │ │ 14-Bits 14-Bits │ │ Packet Command 4-Bits } Buffer[com*8]:=meanPos ' determine on which position in the Buffer to write Buffer[com*8+4]:=meanNeg com++ hsTX.TX(TX_Pin,B_Size,@Buffer,com,Offset) ' Transmit Data to External PropellerAnyway, it worksStill had no time to set up the RS485 or have a look at Propforth
How can I mark the thread "solved"?
Thanks to all!
Cheers
1. Go back to your first thread
2. Select Edit
3. Choose "Go to Advance"
4. At prefix, select "Solved"
Cheers
Kenichi