I need a good control scheme for inter-Prop communication

idbruce · 2011-01-01 04:31

Hello Everyone

I have finally dived into programming two of my CNC machines and I am looking for some good programming stategy for my inter-Prop communications. The following is a diagram which describes the setup:

Packaging CNC Prop <-> Control Panel Prop <-> Bender CNC Prop

As you can see in the diagram above, the Control Panel Prop is the master. The Control Panel Prop monitors and controls several rotary switches, an array of 16 pushbutton switches, a LCD display, and a piezo siren. The Control Panel Prop is responsible for interpreting control panel input, inputting and outputting data to and from the LCD display, and relaying both commands and data to the Packaging CNC Prop and the Bender CNC Prop.

Now that you have a general idea of the setup, here is what I really need. I need a good method for exchanging both commands and data between Props. The following is a few examples of what I mean:

1. A pushbutton has been pressed on the control panel, and this button is intended to instruct the Bender CNC Prop to cut a piece of wire (Example of a command)

2. Several buttons have been pressed on the control panel which are intended to indicate a specific numerical value (Example of data)

I would imagine the best way to differentiate between commands and data, would be to assign a specific character to indicate a command and a specific character to indicate data, and send these characters before sending the command or data.

Any suggestions would be most appreciated.

Bruce

bsnut · 2011-01-01 07:21

Bruce,

Tell me more about your CNC. Such as the stepper drives I/O, pushbuttons and HMI (display) Is it a milling machine for metal?

I have been around machine shop equipment (Brown&Sharp and Monarch) for last 15 years, with Baltimore Streetcar Museum. These machines are manual machines that we use to make parts for are trolley cars, which I provide electronics and electrical support for.

You have the right idea and how I would go about it is.
1) Propeller for scanning I/O and running the CNC parts program, that transfer from the HMI through a comms port. The I/O can be connected via Opto22 Board.
2. The second propeller can handle HMI interface. But they are displays, that are touch screen on the market that have the communications ports built-in. These HMI interfaces also can the user inputs for machine setup. This will save you one propeller, if want.

I will be happy to work with you.

idbruce · 2011-01-01 07:58

bsnut

Both machines are built and wired. Between the two machines, I am using (11) - G251 Stepper Drives from Gecko Drive and to run the drives, I am using my Trapezoidal Ramping PWM Stepper Driver object, aliased G251DriverV4, which can be found in the OBEX at http://obex.parallax.com/objects/693/. The Bending CNC is a wire bender, which will bend spring wire into a predetermined form. The packaging machine packages a specified quantity of the wire form into clamshell type packages. All motors are from Applied Motion and range in size from NEMA 17 - NEMA 23.

The control panel consists of the following:

1. (1) - Allen Bradley series 800T power switch
2. (2) - Allen Bradley series 800A rotary switches
3. (16) - Allen Bradley series 800A pushbutton switches attached to a MM74C922
4. (1) - DataVision 2 x 20 character Hitachi 44780 based LCD module
5. (1) - Serial port for programming the Control Panel Prop
6. (1) - Serial port for programming the Bender CNC Prop
7. (1) - Pot for controlling LCD contrast
8. (1) - Piezo speaker for audible indication of machine error

Of course this description is all over-simplified. Between the two machines, it is a very complex setup. For the last two days I have been programming, testing, and working out the bugs. Won't be long now.

Bruce

JonnyMac · 2011-01-01 08:17

If you're got a free cog in each controller adding serial would be easy. At my company (EFX-TEK), we're beginning to add RS-485 hardware to all of our Propeller-based accessory products to allow them to be interconnected to many systems (DMX, ModBus, custom, etc.)

idbruce · 2011-01-01 08:39

To All Concerned

All three boards are already wired for inter-communication, I am just looking for suggestions pertaining to the exchange of communications as stated in the initial post. To simplify matters, I will be using the FullDuplexSerial object.

Bruce

Duane Degn · 2011-01-01 09:36

idbruce,

I use a lot Propellers that need to communicate with each other.

I use the lower ASCII characters as control characters. Each commuincation starts with $01 followed by $02. When a Prop sees these two characters it knows to pay attention to what is coming next.

The third character is a letter indicating the destination board. Since some of my Props have wireless communication and some are wired (I'm using RS-232 and recently RS-485, I learned from Jon), the wireless Props often have to pass a message on to the wired only Props.

The fourth character is a letter designating the originating Prop. The fifth character is one of three possible:

  _Command = 4                 '  Use to indicate action required by other Prop such as lighting a LED
  _Enquire = 5                     '  Ask about a knob turn or button press
  _Acknowledgment = 6       ' I have actually used this one yet

Here, I found my full list:

  #0, _Null, _StartOfHeader, _StartOfText, _SendToWireLess, _Command, _Enquire, _Acknowledgment, { 0-6
    _Enquire types, Also use in CheckStylusDown method as modes
    } _Button, _ButtonAndKnob, _ButtonKnobAndKey, _ButtonKnobKeyAndNunchuck, _LedSingle, _LedGroup, { 7-12
    } _CarriageReturn, _StopTxNunchuckToRoboni0, _StartTxNunchuckToRoboni0   {13-15}

For wireless communication I add an incrementing counter if I need to make sure each transmission is received. I plan to add a checksum on critical data.

The AX-12s robot controllers by Dynamixel use a communication protocol that I think is worth imitating. You can find manuals for these online.

One dilemma I've found is whether or not to sent numerical data as ASCII characters or not. If you use ASCII, you have to convert it before and after you send the information. If you don't use ASCII, you need to know how long a communication packet is (as the AX-12s do). I usually send my numerical data in ASCII. None of my data has to travel particularly fast. It looks like speed could be a major consideration with what you are doing.

If you're interested in looking at the Dynamixel protocol I'm sure I could find a link to their manual. Found it.

I'm also willing to share my horribly disfigured code with you if you'd like to take a look at what I've done.

As I've been writing this, I remember what others have said on the topic of Prop to Prop com. "It depends on what you want to do." I realize my method works well for me since I need to keep track of the target Prop and the Prop starting the communication. You wouldn't need all the things I do in Prop to Prop com but probably need things I don't use.

I'd like to see what others do for Prop to Prop communication. My system works well enough for me but I feel like it isn't very "graceful."

Duane

idbruce · 2011-01-01 09:53

Duane

First off, thank you for responding, and the same for everyone else that has responded.

All of my Props are hardwired, and each Prop to Prop has it's own set of communication pins(lines), so identification should not be an issue for me.

Speed might seem critical in my situation, but it isn't. There are two main situations where communication is necessary:

During intitial setup before production starts.
And after production starts communication is necessary for an emergency stop in case of machine error or the stop button is pressed, in which case, 1 or 2 seconds to shut down is alright with me, although I am sure it will be much faster.

I appreciate the information, and I may get back to you on seeing how you do it within some code.

Thanks Very Much

Bruce

kwinn · 2011-01-01 09:54

I would suggest standardizing on Timmoore's 4 port serial object since one of your props appear to need 2 ports, and using a protocol that sends ascii characters. Having human readable characters makes debugging much easier.

idbruce · 2011-01-01 09:56

Thanks Kwinn

I will take a look at that object later today. Thanks for the info.

Bruce

kbash · 2011-01-01 13:11

Idbruce,

I built a board with three Props on it for a machine control application similar to your CNC. I needed to keep all three Props synced with each other, switches, process and such, so I used two pins hooked up between all three Props. ( with a pullup resistor on both lines ) One line was a dedicated clock, and the other for data between all the Propellers. Using one Prop as the master, it sent a SYNC signal on the clock line and then a sequence of 288 clock pulses. Each prop had it's own dedicated block of 96 bits for output for a total transmission "Packet" of 288 bits. Each Prop "Knew" when it was it's turn to send it's own 96 bits of data, thereby keeping the other two processors aware of a switch press, limit hit, end of a function call, etc, by setting a "Flag" bit in it's own 96 bit block.

I could also share values by setting flags that indicated that the following 64 bits were a value for something ( temperature, RPM, position , etc ). I wrote it in spin so my data rate was terrible, and it used up a cog in each Prop, but it worked fine for what I needed. (gee... I only had 21 cogs left... ) I know that Beau posted a very fast Prop-Prop com function not long ago, I haven't looked at it, but It might be a great place to start. If multiple props could be hooked into the same data line and each processor take it's turn sending out a packet for the others, it might give you close to the same thing as "Shared Ram" My three prop "Packet" program was far from elegant, but it let me get the job done.
Ken B.

Cluso99 · 2011-01-01 16:22

Bruce: Using FDX is probably the simplest as you have found.

There are other solutions such as Beau's high speed serial code which is what I intended using between my props. I intended using extra bits plus the byte to embedd the command data, so maybe sending a string of 12 bits as an example. Back to your simpler solution...

I would embed the cammands and data into a data structure using the ASCII characters as they were intended back in the days when synchronous protocols were predominant. Just use asynchronous because it is easier. Here is an example...

METHOD 1

STX <command> <length> <data bytes> ETX

STX is the beginning ASCII byte (IIRC $02)
<command> is an ascii byte which you can determine. Use 1 byte to indicate no command i.e. data only, if you require.
<length> is a byte containting the length of the whole string
<data bytes> is an optional number of data bytes
ETX is the ending ASCII byte (IIRC $04)

Sometimes with such a protocol, a reply is sent back to acknowledge receipt... either an ACK (positive acknowledgement) or NACK (negative acknowledgement)

This method (with the <length> attribute) allows for data $00-$FF which may include STX and ETX.

METHOD 2

Use the DLE character as follows...

DLE <sequence of command/data>
Used without a terminator, so the length is known by the sequence.
DLE (data link escape) is used as the start sequence character. When a DLE character is included in the data it has to be preceeded by another DLE character so that DLE+DLE= a real $character.

Hope this may help you. Perhaps a look at the IBM 2780 protocol spec may help - but it may confuse you more.

idbruce · 2011-01-01 16:47

Cluso99

Thank you very much, that was very informative and it made me think. Method 1 looks very enticing, I think I will run with that.

Thanks Again

Bruce

Cluso99 · 2011-01-02 02:09

Bruce: You are welcome and I will keep checking how you go. I did a lot of sync comms programming back in the 70's & 80's.

I need a good control scheme for inter-Prop communication

Comments