I noticed that in 5,956,248 Toro's attorney had a pretty easy job, because only one reference was cited, but in 6,459,959 he really had his work cut out for him, because 16 references were cited in that one. I see you were even into microprocessors back then.
As for 6,076,994 well that looked like it would have been a fun project. I don't know if you ever heard of Task Force Tips, but they did something similar. They revolutionized the firefighting water nozzle industry, and their business started right down the street from where I grew up. Anyhow they modified a swimming pool for testing their fire nozzles. They would pump water from an inlet at the bottom of the pool to an outlet which sat on top of the pool deck. They would attach their nozzles to this outlet and shoot water into this backstop, which would then flow back into the pool creating a whirlpool. By being in the water at testing time, you could float around the pool at approximately 10 RPM. It was wild stuff.
You gave little information on your stream. Is the end of each command terminated by a known character -- a CR, for example? If so, you might do something like this (pulling this from my backside, so be careful):
This is the actual setup:
SLAVE#1 <-> MASTER <-> SLAVE#2
SLAVE#1 is attached to the bending machine, and it is responsible for making the actual product.
SLAVE#2 is attached to the packaging machine, and of course it is responsible for packaging the product.
MASTER is housed within the bending machine alongside the bender electronics. The primary purpose of the MASTER is to accept input and parameters from the user interface, interpret the input and parameters, and then issue the appropriate commands to SLAVE#1 or SLAVE#2. However, this will mostly occur during initial setup procedures before a production run. The MASTER will handle time clock setup, issue commands for machine calibration, and provide runtime parameters for both machines. After setup and during runtime, with the exception of an E-Stop, the MASTER will simply act as a "go between", passing information from one machine to another.
And here is something similar to what I will implement:
Bender Commands For Machine Calibration:
B10:0000000CR - Cut Wire (Raise and lower cutter to default positions)
B11:0002000CR - Raise Cutter by 2000 steps
B12:0003500CR - Lower cutter by 3500 steps
B13:0000500CR - Feed wire by 500 steps
B14:0000000CR - Rotate bending head CCW to default CW bending position
B15:0000350CR - Rotate bending head CCW by 350 steps
B16:0000000CR - Rotate bending head CW to default CCW bending position
B17:0000450CR - Rotate bending head CW by 450 steps
ETC.... and so on
Packaging Commands For Machine Calibration
P10:0000000CR - Move lid closer to default position
ETC.... and so on
Runtime Parameters
R10:0000001CR - Product Size
R11:0040000CR - Produce 40,000 units
R12:0000025CR - Quantity of 25 per package
R13:0000001CR - Production Speed Level of 1
ETC.... and so on
During setup, the time length between the issuance of these commands will vary. All depending on the complexity of the setup. Average time length between commands 15 sec - 5 minutes.
Once the machines are in production mode, intercommunication would only occur approximatimately every 8 minutes.
However, there are exceptions. Such as:
Machine error or emergencey stop.
Well, there you have it: the command strings are terminated with a CR so the little keyboard demo (which is expecting a CR termination) will be very easy to adapt. You can always use rxcheck in the FDS object to see if there is anything in the serial buffer; when there is you can move that to your parsing buffer.
Back on Feb 2 2010 I had posted a thread with assembly code to do Prop to Prop communications in ASCII character format, and tuned to run at 5 Mb/s. The programs are in assembler (I still don't know Spin), very tiny, "rock solid" and reasonably well commented. It allows you to transmit a continuous stream of data stored in hub to another Prop where it will dump the received stream into the its hub.
The beauty of this is that, unlike many of the other serial comms offerings, it has no pre-specified buffer length, and can stream without interruption for as much as the whole hub ram size.
Your own application needs to take care of supplying and taking care of the data in the hub ram, so it is in fact a "snippet", or engine if you will, to be encapsulated into somthing bigger that will take care of error checking etc.
The transmitter can be set up to dump specified number of characters, or until it senses a null.
The receiver can be set up to pull in a specified number of characters, or terminate on detecting a leading or trailing "no-data" time-out period.
It might be of some interest to you, and if so, you will have to look the thread up "5Mbit/sec ASCII Streaming From/To HubRam" as I don't know how to link this reply to it (PC ingoramus).
Bruce,
I would suggest some kind of error checking. This could be as simple as sending two characters for the command and sending the numbers twice with different delimiters (like ":" and ";"), then comparing the two copies of the numbers and stopping everything if there's a mismatch. Alternatively, the receiver could send an acknowledgement or rejection code back to the transmitter and the transmitter could resend the whole thing again if needed with a maximum number of retries allowed before an emergency stop. You'd want to have a timeout for the receiver as well as an acknowledgement timeout in the transmitter.
In the setup you've described, there's probably a distance of a couple of feet between devices and it's an electrically noisy environment. Consider using RS232 signal levels (with a MAX3232 3.3V logic to RS232 converter) or maybe RS485 (balanced) with a MAX3488E. You may do fine just using twisted pairs for wiring, maybe shielded too if it's a noisy environment.
@pjv - Thanks I will take a look. Right now, I am looking for all the information and guidance I can get pertaining to this issue. It is of the utmost importance to me. Thanks Peter
@Mike- I would have to definitely agree about the error checking. I like your suggestions. Everything is wired and ready to go, if I need a MAX3232 I'm screwed, because there just isn't room for it. From slave1 to the master there is about a six inch piece of shielded cable between the two (untwisted). As for the connection between slave 2 and the master, there is a distance of approximately 3 feet. That connection is also shielded cable (untwisted). If necessary, and even if it is not, I will probably make some new cables using twisted shielded cable.
I had to take a break this morning because of all the stress and pressure. Now my goal is baby steps just to make communication happen. Once I truly understand the whole process, then I can get into moving the data around, error checking, etc...
My first attempt will be to communicate through the user interface through the master and onto slave 1 to get the wire feeder to rotate exactly 1 revolution. Once I can make that happen, I believe I am home free.
Thanks for your input Mike, those were some very good suggestions.
This is a culmination of ideas which resulted from discussions with JonnyMac, Mike Green, and Cluso99, and it applies to sending data between two prop chips.
It was originally discussed that I was going to send data similar to "B15:0000350CR"
Broken down, this is equivalent to B - Bender CNC, 15 - Machine Operation, : - Delimiter, 350 - Step Count For Motors, CR - End Of Data
JonnyMac presented me with a good code example that helped me get a fairly good grasp on intercommunication and would have accomplished transmissions perfectly. Please refer to his sample above for further details.
However, after further research and much deliberation, I have come up with a new data transmission scheme, which is as follows:
Between my two CNC machines which must interact with each other, there is a command set of approximately 30 functions. So instead of prefixing the command with a letter, I have decided to just eliminate it and provide a numeric command indicator of 10 - 40.
And instead of having a colon as a delimiter, I have decided to just use a decimal point as my delimiter for seperating the command from the required steps.
And finally, the number of required steps will follow the decimal point. So what was once "B15:0000350" has now become "15.350". By using the Extended Full Duplex Serial Object, it will be quite easy to seperate the command from the rquired number of steps.
In addition to the forementioned changes, the following changes will also be implemented.
STX (2) Start Of Text - Will be used to indicate the beginning of a new transmission
To ensure data accuracy a cyclic redundancy check will be performed on the data. And the result of this cyclic redundancy check will be attached to the data stream. The following snippet utilized for the cyclic redundancy check was provided by Dave Hein in another post.
PUB ComputeCRC(ptr, num)
repeat num
result ^= (byte[ptr++] << 8)
repeat 8
result <<= 1
if result & $10000
result ^= $1021
result &= $ffff
Dave Hein, Said:
The code that I posted will generate the stadard ITU 16-bit CRC for a block of "num" bytes starting at the address in "ptr".
US (31) Unit Seperator - Will be used as a delimiter to seperate the command from the cyclic redundancy check result
ETX (3) End Of Text - Will be used to indicate the end of the transmission
Keeping inline with the previous example the data stream is now something similar to the following:
"B15:0000350" is now "STX, 15.350, US, CRC_RESULT, ETX
Upon sending the data stream, the sender will wait for a specified period of time for the receipt of either:
ACK (6) Acknowledge - Indication of successful receipt of a message
NAK (21) Negative Acknowledge - Indication of unsuccessful receipt of a message
If a NAK result is received the sender will make several attempts to resend the data until a ACK is received.
As for the connection between slave 2 and the master, there is a distance of approximately 3 feet. That connection is also shielded cable (untwisted). If necessary, and even if it is not, I will probably make some new cables using twisted shielded cable.
For slow speeds that should work fine. No need for max232/485's etc. Just use a 1k resistor between the propellers. Ballpark, I've got 1200 baud to go more than 100 metres, and for 3 feet twisted pair or shielded, even 115200 ought to be possible. Probably more, and if you have error correction you could do a printout of the number of errors so you can see if you are getting close to the speed limit for that cable.
Such is my hope. But just to ensure data integrity, I will change the cable at a later date to a shielded twisted pair. As Mike said, it will be a very noisy environment with all those motors, solenoids, RF control modules, and etc....
Bruce: Sounds good. The <us> of course is not required, but makes it easier to locate the crcc. Dont forget if you dont see an ack or nak after a timeout, it is presumed to be a nak (just in case you didnt think of it now).
Shielded twisted pair should be fine. However, I would use at least 3 wire plus shield. What about power - do they each ahve separate power. Now, why 3 plus shield. Because in noisy environments, the gnd is a wire and the shield is connected one end to gnd (usually the master) and the other end is connected by a high voltage cap, say 330nF 250v which stops any possibility of earth loops. This is particularly relevant in star networks and long distances (~100s meters).
Now, if the environment is really noisy, you could use RS485 modules. IIRC Bill Henning has some of these.
Actually, the shield should only be connected at one end and left open at the other. The reason is that you don't want any currents running through the shield. A separate ground wire (not the drain wire) should be connected at both ends. BTW, twisted-pair cable is advantageous only for balanced differential signals, such as RS422, RS485, ethernet, etc.
Thanks for the info Phil. I always thought that twisted pair was better for most situations. Currently, I just have a shielded untwisted 4 conductor cable with one conductor being unused, however the shield is not connected to anything. If it is useless to install twisted pair in my case, I guess from here on in, I better just keep my toes and fingers crossed
You might still want to consider the advantages of RS422/485, along with twisted pair cable, in an industrial environment -- even for short runs. Problems caused after the fact by electrical noise are the least fun to solve. Putting some additional effort up front can pay big dividends down the road.
There is no doubt in mind that you are telling me the truth, however, out of 3 proto boards, 2 of them are filled to capacity. On one board there is no space or pins remaining, on another board, there are 2 pins with no space remaining, and on the third board I have approx. 10 spare pins and plenty of space. Needless to say my options are limited unless I become very creative
It's not difficult to add a mezzanine board with the additional circuitry. The Parallax Proto-DB can be used without the included 2mm connector and has plenty of available holes on 0.1" centers for a transceiver chip and connectors.
The minis I worked with had 50kb comms using a peculiar serial style protocol (before UARTS) that clocked at ~17.5us and would run successfully over distances in excess of 1km. It was +-5V signalling using 2 wire twisted shielded cable. You can imagine the mini with 10-30 screens located around a complex and the wiring typically running beside 240V cabling. Sometimes we found that the screens were better connected at the terminal ends with capacitors to ground and other times best without, even on the same site. One site ran cable in an underground conduit together with 240v for ~1km to another hanger at a small airport. I think it was more to do with the terminal's flaws than anything. The most problems were with operators with nylon nickers (true!).
FYI the terminal ends of the cable were via a ferrite core xformer. The 2 wires were balanced bi-directional switched by transistors to +5V & -5V as I said above. I designed terminal interfaces and soft coded the equivalent of the serial uart interface for over 20 years.
So, if you have problems, I agree with Phil, use RS422 or RS485. A tiny daughter-pcb will resolve this should you need to. Therefore, I would suggest you might use CAT5 cable with shield, just in case you require it later.
In the USA the electrical inspectors would give us a good spanking for putting 5v cables with 240v cables inside conduit. I hate to think of the welts.
In the USA the electrical inspectors would give us a good spanking for putting 5v cables with 240v cables inside conduit.
It happens, though. Many years ago, one of my most pernicious installation problems occurred because the customer ran my multi-drop network cable through a conduit carrying a 440VAC conveyor supply. This was how I learned (the hard way) not to ground both ends of a cable's shielding.
I have done it once or twice myself. Not proud of it, but I have done it. Certainly not with anything above 120V though. I have seen many electricians get red tags in romex installations for shoving a doorbell tranformer in the same box as romex, and then slapping the doorbell on top of it. It is legal, but it must be a two gang box and it must have a seperator for the 12-24V / 120V wiring.
Thanks for the info Phil. I always thought that twisted pair was better for most situations. Currently, I just have a shielded untwisted 4 conductor cable with one conductor being unused, however the shield is not connected to anything. If it is useless to install twisted pair in my case, I guess from here on in, I better just keep my toes and fingers crossed
Do you have a separate power supply for that board 3 foot away?
Or are you running another two wires for power?
There are a number of different layouts that are possible here - eg separate mains transformers/supplies, or one supply and send a higher voltage to the other boards and regulate it on the board. Or even (for short runs) send 3.3V regulated to other boards.
I agree with only grounding one end of the shield.
Presumably one of the wires out of the 4 is also 'ground' and it would be helpful to know what the supply layout is, as there is potential for interference to enter via supply lines as well.
In general terms, I suspect with 3 foot runs, you ought to have no problems with interference with slow baud rates. Ballpark with speeds, I had a terminal once with unshielded untwisted wires at RS232 voltage levels at 5 metres that started to show problems at 19200 baud.
Ok. I think you said your board was almost full, so with those specs, I reckon it should work with direct pin to pin. Shield with one end grounded. 3 wires inside - one for Gnd, one fo Tx and one for Rx.
1k resistors in the Tx and Rx link? No need to make this any complicated than it needs to be. 9600 is a rock solid sort of speed at these distances.
Put a trace on your error subroutine (printout, led flash or whatever) and I'd be surprised if it ever gets triggered.
CON
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
BUFFER_SIZE = 80
#1, HOME, GOTOXY, #8, BKSP, TAB, LF, CLREOL, CLRDN, CR
#14, GOTOX, GOTOY, CLS
VAR
BYTE Buffer[BUFFER_SIZE]
OBJ
FDS : "Extended_FDSerial"
PUB Main | Index
FDS.Start(31, 30, 0, 115_200)
WAITCNT(CLKFREQ * 2 + CNT)
FDS.tx(CLS)
FDS.rxflush
repeat until FDS.rxDec == 2
FDS.str(string("A 2 has been found! Start filling the buffer!", CR))
bytefill(@Buffer, 0, BUFFER_SIZE)
index := 0
repeat while FDS.rxDec <> 3
Buffer[Index] := FDS.rx 'I am attempting to fill the buffer here with no success
Index++
FDS.str(string("Buffer filling has ended!", CR))
' Here I would like to display the infomation within the buffer
Something in the spirit of this should do (works for me that is):
CON
_CLKMODE = XTAL1 + PLL16X
_XINFREQ = 5_000_000
BUFFER_SIZE = 80
#1, HOME, GOTOXY, #8, BKSP, TAB, LF, CLREOL, CLRDN, CR
#14, GOTOX, GOTOY, CLS
VAR
BYTE Buffer[BUFFER_SIZE]
OBJ
FDS : "Extended_FDSerial"
PUB Main | Index[COLOR="red"], c[/COLOR]
FDS.Start(31, 30, 0, 115_200)
WAITCNT(CLKFREQ * 2 + CNT)
FDS.tx(CLS)
FDS.rxflush
repeat until FDS.rxDec == 2
FDS.str(string("A 2 has been found! Start filling the buffer!", CR))
bytefill(@Buffer, 0, BUFFER_SIZE)
index := 0
repeat while [COLOR="red"](c := FDS.rx) <> "3"[/COLOR]
Buffer[Index] := [COLOR="red"]c[/COLOR] 'I am attempting to fill the buffer here with no success
Index++
FDS.str(string("Buffer filling has ended!", CR))
' Here I would like to display the infomation within the buffer
After re-reading the thread I noticed
STX (2) Start Of Text - Will be used to indicate the beginning of a new transmission
ETX (3) End Of Text - Will be used to indicate the end of the transmission
In that case you want
repeat while [COLOR="blue"](c := FDS.rx) <> 3[/COLOR]
... and the STX code needs adjusting as well, e.g.
Comments
That's pretty neat, thanks for sharing.
I noticed that in 5,956,248 Toro's attorney had a pretty easy job, because only one reference was cited, but in 6,459,959 he really had his work cut out for him, because 16 references were cited in that one. I see you were even into microprocessors back then.
As for 6,076,994 well that looked like it would have been a fun project. I don't know if you ever heard of Task Force Tips, but they did something similar. They revolutionized the firefighting water nozzle industry, and their business started right down the street from where I grew up. Anyhow they modified a swimming pool for testing their fire nozzles. They would pump water from an inlet at the bottom of the pool to an outlet which sat on top of the pool deck. They would attach their nozzles to this outlet and shoot water into this backstop, which would then flow back into the pool creating a whirlpool. By being in the water at testing time, you could float around the pool at approximately 10 RPM. It was wild stuff.
Bruce
This is the actual setup:
SLAVE#1 <-> MASTER <-> SLAVE#2
SLAVE#1 is attached to the bending machine, and it is responsible for making the actual product.
SLAVE#2 is attached to the packaging machine, and of course it is responsible for packaging the product.
MASTER is housed within the bending machine alongside the bender electronics. The primary purpose of the MASTER is to accept input and parameters from the user interface, interpret the input and parameters, and then issue the appropriate commands to SLAVE#1 or SLAVE#2. However, this will mostly occur during initial setup procedures before a production run. The MASTER will handle time clock setup, issue commands for machine calibration, and provide runtime parameters for both machines. After setup and during runtime, with the exception of an E-Stop, the MASTER will simply act as a "go between", passing information from one machine to another.
And here is something similar to what I will implement:
Bender Commands For Machine Calibration:
B10:0000000CR - Cut Wire (Raise and lower cutter to default positions)
B11:0002000CR - Raise Cutter by 2000 steps
B12:0003500CR - Lower cutter by 3500 steps
B13:0000500CR - Feed wire by 500 steps
B14:0000000CR - Rotate bending head CCW to default CW bending position
B15:0000350CR - Rotate bending head CCW by 350 steps
B16:0000000CR - Rotate bending head CW to default CCW bending position
B17:0000450CR - Rotate bending head CW by 450 steps
ETC.... and so on
Packaging Commands For Machine Calibration
P10:0000000CR - Move lid closer to default position
ETC.... and so on
Runtime Parameters
R10:0000001CR - Product Size
R11:0040000CR - Produce 40,000 units
R12:0000025CR - Quantity of 25 per package
R13:0000001CR - Production Speed Level of 1
ETC.... and so on
During setup, the time length between the issuance of these commands will vary. All depending on the complexity of the setup. Average time length between commands 15 sec - 5 minutes.
Once the machines are in production mode, intercommunication would only occur approximatimately every 8 minutes.
However, there are exceptions. Such as:
Machine error or emergencey stop.
Bruce
Yea, it should be perfect for me. I will spend this morning trying it out to see if I can actually get them to communicate. Thanks Jon
However, one thing I just realized. I should definitely remove all those unnecessary zeros that I am adding before the actual value that I want. DUH
Bruce
Back on Feb 2 2010 I had posted a thread with assembly code to do Prop to Prop communications in ASCII character format, and tuned to run at 5 Mb/s. The programs are in assembler (I still don't know Spin), very tiny, "rock solid" and reasonably well commented. It allows you to transmit a continuous stream of data stored in hub to another Prop where it will dump the received stream into the its hub.
The beauty of this is that, unlike many of the other serial comms offerings, it has no pre-specified buffer length, and can stream without interruption for as much as the whole hub ram size.
Your own application needs to take care of supplying and taking care of the data in the hub ram, so it is in fact a "snippet", or engine if you will, to be encapsulated into somthing bigger that will take care of error checking etc.
The transmitter can be set up to dump specified number of characters, or until it senses a null.
The receiver can be set up to pull in a specified number of characters, or terminate on detecting a leading or trailing "no-data" time-out period.
It might be of some interest to you, and if so, you will have to look the thread up "5Mbit/sec ASCII Streaming From/To HubRam" as I don't know how to link this reply to it (PC ingoramus).
Cheers,
Peter (pjv)
I would suggest some kind of error checking. This could be as simple as sending two characters for the command and sending the numbers twice with different delimiters (like ":" and ";"), then comparing the two copies of the numbers and stopping everything if there's a mismatch. Alternatively, the receiver could send an acknowledgement or rejection code back to the transmitter and the transmitter could resend the whole thing again if needed with a maximum number of retries allowed before an emergency stop. You'd want to have a timeout for the receiver as well as an acknowledgement timeout in the transmitter.
In the setup you've described, there's probably a distance of a couple of feet between devices and it's an electrically noisy environment. Consider using RS232 signal levels (with a MAX3232 3.3V logic to RS232 converter) or maybe RS485 (balanced) with a MAX3488E. You may do fine just using twisted pairs for wiring, maybe shielded too if it's a noisy environment.
@Mike- I would have to definitely agree about the error checking. I like your suggestions. Everything is wired and ready to go, if I need a MAX3232 I'm screwed, because there just isn't room for it. From slave1 to the master there is about a six inch piece of shielded cable between the two (untwisted). As for the connection between slave 2 and the master, there is a distance of approximately 3 feet. That connection is also shielded cable (untwisted). If necessary, and even if it is not, I will probably make some new cables using twisted shielded cable.
I had to take a break this morning because of all the stress and pressure. Now my goal is baby steps just to make communication happen. Once I truly understand the whole process, then I can get into moving the data around, error checking, etc...
My first attempt will be to communicate through the user interface through the master and onto slave 1 to get the wire feeder to rotate exactly 1 revolution. Once I can make that happen, I believe I am home free.
Thanks for your input Mike, those were some very good suggestions.
Bruce
This is a culmination of ideas which resulted from discussions with JonnyMac, Mike Green, and Cluso99, and it applies to sending data between two prop chips.
It was originally discussed that I was going to send data similar to "B15:0000350CR"
Broken down, this is equivalent to B - Bender CNC, 15 - Machine Operation, : - Delimiter, 350 - Step Count For Motors, CR - End Of Data
JonnyMac presented me with a good code example that helped me get a fairly good grasp on intercommunication and would have accomplished transmissions perfectly. Please refer to his sample above for further details.
However, after further research and much deliberation, I have come up with a new data transmission scheme, which is as follows:
And instead of having a colon as a delimiter, I have decided to just use a decimal point as my delimiter for seperating the command from the required steps.
And finally, the number of required steps will follow the decimal point. So what was once "B15:0000350" has now become "15.350". By using the Extended Full Duplex Serial Object, it will be quite easy to seperate the command from the rquired number of steps.
To ensure data accuracy a cyclic redundancy check will be performed on the data. And the result of this cyclic redundancy check will be attached to the data stream. The following snippet utilized for the cyclic redundancy check was provided by Dave Hein in another post.
PUB ComputeCRC(ptr, num) repeat num result ^= (byte[ptr++] << 8) repeat 8 result <<= 1 if result & $10000 result ^= $1021 result &= $ffffDave Hein, Said:
ETX (3) End Of Text - Will be used to indicate the end of the transmission
NAK (21) Negative Acknowledge - Indication of unsuccessful receipt of a message
Hope you found this interesting.
Bruce
For slow speeds that should work fine. No need for max232/485's etc. Just use a 1k resistor between the propellers. Ballpark, I've got 1200 baud to go more than 100 metres, and for 3 feet twisted pair or shielded, even 115200 ought to be possible. Probably more, and if you have error correction you could do a printout of the number of errors so you can see if you are getting close to the speed limit for that cable.
Such is my hope. But just to ensure data integrity, I will change the cable at a later date to a shielded twisted pair. As Mike said, it will be a very noisy environment with all those motors, solenoids, RF control modules, and etc....
Bruce
Shielded twisted pair should be fine. However, I would use at least 3 wire plus shield. What about power - do they each ahve separate power. Now, why 3 plus shield. Because in noisy environments, the gnd is a wire and the shield is connected one end to gnd (usually the master) and the other end is connected by a high voltage cap, say 330nF 250v which stops any possibility of earth loops. This is particularly relevant in star networks and long distances (~100s meters).
Now, if the environment is really noisy, you could use RS485 modules. IIRC Bill Henning has some of these.
Actually, I will go with shielded 4 conductor, with each pair twisted, and one wire being unused. Like so:
TX <- RX
VSS <-> VSS
I may have to go back to Jons code, because this new parser and pointers are being a real pain for me, and I am eager to get the machine going.
Bruce
-Phil
Thanks for the info Phil. I always thought that twisted pair was better for most situations. Currently, I just have a shielded untwisted 4 conductor cable with one conductor being unused, however the shield is not connected to anything. If it is useless to install twisted pair in my case, I guess from here on in, I better just keep my toes and fingers crossed
Bruce
In answer to one of your questions that I missed. The master and Slave 1 run off the same power supply.
Bruce
-Phil
There is no doubt in mind that you are telling me the truth, however, out of 3 proto boards, 2 of them are filled to capacity. On one board there is no space or pins remaining, on another board, there are 2 pins with no space remaining, and on the third board I have approx. 10 spare pins and plenty of space. Needless to say my options are limited unless I become very creative
Bruce
-Phil
FYI the terminal ends of the cable were via a ferrite core xformer. The 2 wires were balanced bi-directional switched by transistors to +5V & -5V as I said above. I designed terminal interfaces and soft coded the equivalent of the serial uart interface for over 20 years.
So, if you have problems, I agree with Phil, use RS422 or RS485. A tiny daughter-pcb will resolve this should you need to. Therefore, I would suggest you might use CAT5 cable with shield, just in case you require it later.
In the USA the electrical inspectors would give us a good spanking for putting 5v cables with 240v cables inside conduit. I hate to think of the welts.
Bruce
Yea that board is pretty cool. I don't think I ever seen it before.
Bruce
-Phil
I have done it once or twice myself. Not proud of it, but I have done it. Certainly not with anything above 120V though. I have seen many electricians get red tags in romex installations for shoving a doorbell tranformer in the same box as romex, and then slapping the doorbell on top of it. It is legal, but it must be a two gang box and it must have a seperator for the 12-24V / 120V wiring.
Bruce
Do you have a separate power supply for that board 3 foot away?
Or are you running another two wires for power?
There are a number of different layouts that are possible here - eg separate mains transformers/supplies, or one supply and send a higher voltage to the other boards and regulate it on the board. Or even (for short runs) send 3.3V regulated to other boards.
I agree with only grounding one end of the shield.
Presumably one of the wires out of the 4 is also 'ground' and it would be helpful to know what the supply layout is, as there is potential for interference to enter via supply lines as well.
In general terms, I suspect with 3 foot runs, you ought to have no problems with interference with slow baud rates. Ballpark with speeds, I had a terminal once with unshielded untwisted wires at RS232 voltage levels at 5 metres that started to show problems at 19200 baud.
How fast does the comms link need to be?
Yes there is a seperate power supply for the board 3 feet away.
For the size of the information that I will be passing, even at low baud rate of 9600, transmissions should be complete almost instantaneously.
Bruce
1k resistors in the Tx and Rx link? No need to make this any complicated than it needs to be. 9600 is a rock solid sort of speed at these distances.
Put a trace on your error subroutine (printout, led flash or whatever) and I'd be surprised if it ever gets triggered.
CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 BUFFER_SIZE = 80 #1, HOME, GOTOXY, #8, BKSP, TAB, LF, CLREOL, CLRDN, CR #14, GOTOX, GOTOY, CLS VAR BYTE Buffer[BUFFER_SIZE] OBJ FDS : "Extended_FDSerial" PUB Main | Index FDS.Start(31, 30, 0, 115_200) WAITCNT(CLKFREQ * 2 + CNT) FDS.tx(CLS) FDS.rxflush repeat until FDS.rxDec == 2 FDS.str(string("A 2 has been found! Start filling the buffer!", CR)) bytefill(@Buffer, 0, BUFFER_SIZE) index := 0 repeat while FDS.rxDec <> 3 Buffer[Index] := FDS.rx 'I am attempting to fill the buffer here with no success Index++ FDS.str(string("Buffer filling has ended!", CR)) ' Here I would like to display the infomation within the bufferCON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 BUFFER_SIZE = 80 #1, HOME, GOTOXY, #8, BKSP, TAB, LF, CLREOL, CLRDN, CR #14, GOTOX, GOTOY, CLS VAR BYTE Buffer[BUFFER_SIZE] OBJ FDS : "Extended_FDSerial" PUB Main | Index[COLOR="red"], c[/COLOR] FDS.Start(31, 30, 0, 115_200) WAITCNT(CLKFREQ * 2 + CNT) FDS.tx(CLS) FDS.rxflush repeat until FDS.rxDec == 2 FDS.str(string("A 2 has been found! Start filling the buffer!", CR)) bytefill(@Buffer, 0, BUFFER_SIZE) index := 0 repeat while [COLOR="red"](c := FDS.rx) <> "3"[/COLOR] Buffer[Index] := [COLOR="red"]c[/COLOR] 'I am attempting to fill the buffer here with no success Index++ FDS.str(string("Buffer filling has ended!", CR)) ' Here I would like to display the infomation within the bufferAfter re-reading the thread I noticed
In that case you want ... and the STX code needs adjusting as well, e.g.
Also is there another half that is creating the numbers? I'm thinking of ascii "2" vs ascii 2. (decimal 50 vs 02).
I've been where you are now, and hopefully you will get a wonderful euphoric feeling very soon as that first data goes through!