Programming Multiple Props
StephenMoore
Posts: 188
I am using Beau Schwabe's High Speed Prop server code to run a state machine on 5 props. One of the biggest problems is constantly switching serial port connections to make changes on each processor. Is there a way to run multiple instances of the Propeller Tool to dedicate the programmer tool to each processor?
Comments
Edit\Preferences\Operation(tab)\Communication\Serial Port Search (I'm not sure what you do here, but I think this is where you can specify a serial port to use.)
I am running Windows 7.
Is anyone else able to?
I'm on Windows 7 and I have two instances open right now.
I usually open the Prop Tool by double clicking on the Prop Tool's desk top icon.
Did you save the changes you made to preferences? (I forgot to tell you to click "Accept".)
Appreciate your help.
This simplifies dedicating a COM port to a given prop.
On this same subject, you wouldn't by chance know of any control-messaging schemes already setup for multi-prop programming.
I am using a system of command registers and status registers. Each prop has its own dedicated write space in a ring buffer of 500 longs.
It works great but I was wondering if anyone had proposed a sort of "OBEX" standard protocol for this sort of thing.
Again thank you,
sm
You're very welcome.
I know Prop to Prop stuff get talked about time to time on the forum. While I'm sure there are many more threads dealing with this topic, I've only have two of these threads linked to in post #5 of my index.
The only trick I'd add is to use upper EEPROM to store an ID number so all Props can be loaded with the same code and each will know what it's to do based on this number.
One method I use to keep one Prop board from receiving downloaded code is to use the Parallax Serial Terminal to block the com line. Use Prefs...\Function(tab)\(uncheck)Automatically disable (close port) when application is inactive.
By making the above change, the terminal will keep the Prop Tool from using that particular com line. Of course you can also configure the Prop Tool to only use one specific port.
You lawn mower bot sounds very interesting. I hope you start a thread about it.
I followed the above advice and am able to program as many props as necessary with separate instances of the Propeller Tool v 1.3.2. The HS comm program works great. I am still hoping to come up to speed on it myself and maybe condense it into one COG looping between transmit and receive. Each Props' own register space would of course have to be defined and configured before the COGINIT is ran.
My 5 prop controller runs and appears to have a block of 500 longs available to all processors in real time.
Another item I would like to work on is adding a "programming Prop" which does nothing more than load the other Props eeproms with their source code. An alternative might be to use a large Flash RAM for all of the code for all processors.
My thanks goes out to Beau for his very handy interfacing code.
Also, I am told to go to FORTH as a means to accomplish enhanced system development... right now I am on the learning curve.
Regards,
sm
Are you launching the Prop tool then selecting each serial port for the board you want to program? One thing I would like to see if you can set the COM port from the command line or startup icon. That way you can have a desktop icon to launch an instance of the Propeller tool for each board you want to program. It would save time whenever you want to launch the Prop tool. In my case I just leave the propeller boards connected to a hub and then there is just one USB connection to make to the PC.
I have made resistor network cables for the prop to prop and also have actually made a custom resistor network board for prop to prop comm.
I did it in DipTace but it won't let me upload the file so I included a .dxf.
However, I found that to continuously pass variables between props without overwriting RAM, it required two cogs: one cog to coordinate the prop specific data moves into the ring buffer and the HS cog itself.
So, I took the liberty of modifying Mr. Schwabe's object.
The attached demo shows how the new object works (very similar to the original). It now contains both RX and TX modules in the same cog and makes provision to protect user memory within the ring buffer.
For my application of industrial CNC control this will free up 1 cog on each of 5 Props (by my math 5 cogs total). This is really significant. It also eliminates the requirement to duplicate the ring buffer memory to prevent overwrites, so in my instance I save 500 longs on each of the Props for a total of 2500 longs of RAM, again very significant.
This program is essential for our plans to build powerful low cost adaptable controllers for a range of industrial manufacturing processes. The ease of software development with this approach has saved us over 1500 man-hours in 2012.
Thanks Parallax!
sm
Regards,
Mickster
It is all custom stuff. No G-code but similar. There several closed loop digital stepper control algorithms employed.
I am currently working on a pass through bootloader that will allow me to program the whole Prop array from one interface. Do you have any experience with that particular item?
I am told to go to FORTH but it seems like a solution could be had in SPIN/PASM alone if I use something like a C3 board with a large amount of programmable FLASH ram.
The goal is to designate one Prop as the master controller capable of distributing tasks to the COG collective. I know others have worked extensively in this area but I can't quite put my hands on a good starting point.
The HS prop to prop comm is as close as I have gotten so far.
Regards,
sm
I have the encoder quad-decode working and it appears to be good for > 1.5M counts per second. The PID and Feed-forward, etc. is no biggie but I'm now looking at the velocity profiling (trapezoidal for now).
A "standard" for me is to utilize dual-loop feedback wherever a transmission (gear-reducer, etc.) is employed, meaning that I have position feedback from the motor and also the load so I will probably end-up with one physical axis per Prop (one motor command output + two encoder inputs) and the ability to also run virtual axes. I am thinking that 115.2Kbaud will be more than adequate for Prop-to-Prop comms.
Language of choice for me thus far is PropBASIC as it is the most readable language available for the Prop and outputs pure PASM. Can't wait for the P2 as its counters are supposedly configurable for direct quad decode....I wonder what kind of frequency to expect
Regards,
Mickster
We use Gecko stepper drives and magnetic encoders with some degree of success. Right now we are not doing torque/current feedback control but have considered it. You have a pretty sophisticated setup going.
We are very impressed with the ability to distribute control as needed with the HS prop to prop communication scheme. We have eliminated large interrupt driven coding schemes. When we add machine functionality we simply add COG as necessary.
Do you guys have a website?
sm
We started work on this mid-January 2012. It was on the market by June and is selling very well. The first stage was to test the concept/acceptance of the tablet HMI. Encased in billet aluminum, it feels amazing and well suited to the factory environment. The cool thing is that; should you need to replace it, you can get one anywhere. Set the new one up with the appropriate email account and, automatically, the app for that very machine along with cloud-backed-up data and parameters are loaded instantly....try that with an Allen Bradley or whatever
Mickster
The two additional prop chips and the C3 board are all programmed through the PPDB chip using Chip Gracey's LoadPropeller object. It requires 9 pins on the programming chip but I only use one USB port to program all four props. After I am done programming, the programming prop itself joins the prop network as a functioning processor. It also serves as a serial port pass through for debugging each prop with a single instance of Parallax Serial Terminal interface.
The program I am using looks like this:
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 'Propeller enumeration #1, C3, Prop1, Prop2 'Programming pin definitions #2, RESn1, RX1, TX1 #5, RESn2, RX2, TX2 #8, RESn3, RX3, TX3 Prop = C3 ' Prop = Prop1 ' Prop = Prop2 OBJ loader : "PropellerLoader" DAT loadme file "server.binary" ' loadme file "client1.binary" ' loadme file "client2.binary" PUB LoadPropeller case Prop C3: loader.Connect(RESn1, RX1, TX1, 1, loader#ProgramRun, @loadme) Prop1: loader.Connect(RESn2, RX2, TX2, 1, loader#ProgramRun, @loadme) Prop2: loader.Connect(RESn3, RX3, TX3, 1, loader#ProgramRun, @loadme)My question is this. Has anyone found a good way to do conditional compilation so that I can automatically select the appropriate load file and programming pin selections?
As it stands, this system does simplify program loading versus fumbling around with four separate USB connections.
Regards,
sm
I realize everything I've tried to develop here has been re-inventing the wheel but...
I used the PropLoader object as a means to program a network of props. As a point of information, the props are connected with the HScomm object which I condensed to one cog (both TX and RX) which runs without input from any other cogs, but the PropLoader object works through pins RESn, P30 and P31 for each prop. One propeller is dedicated as the programmer chip and is connected to each propeller programming interface (8 props max = 24 pins). After it is done programming it is loaded with any other program to work within the network (e.g as a math co-processor, serial interface for debug, etc)
I wrote a program in LabView to call various functions from the Propellent.DLL file. First it compiles the desired propeller program and then compiles a dedicated PropLoader program for the affected prop and downloads that program to the loader Propeller. Finally it reloads the loader Propeller with its regular spin program. All of this is done with one mouse click. I have attached the LabView vi if anybody is interested. The net result is you simply make edit changes to your spin programs in any editor, save them and hit click in LabView. Everything happens over a single USB port and up to 8 different props get loaded with their appropriate programs.
I am done with this little exercise and have a couple of comments to make:
1) Interfacing multiple props seems like a real advantage and needs to be proposed in an application note in a very straight forward manner
2) The program I wrote in LabView could be functionally available in the Propeller Tool... it is just not that complicated.
3) Since we started using multiple propellers in our projects we have made real gains in product development. This item is by no means becoming obsolete even though the current attention seems focused on P2. I would love to see some enhancement tools made available from Parallax, Inc.
Kindest regards,
sm
I modified the program to read the Propeller system configuration (which pins and programs are used) from a spreadsheet file (.csv). It is a lot easier to use. However, in order to run the Labview program (MultiPropLoader.exe) you must down load the Labview Run-Time Engine from the following link:
http://joule.ni.com/nidu/cds/view/p/id/4059/lang/en
The Run Time Engine is needed for any computer that runs a Labview Application but does not have the Development Software loaded.
The following flowchart describes what goes on.
If you open my PropConfig.csv with a spreadsheet program you can see where the pin and spin program definitions go. I use the spreadsheet to label all of my Propeller IO but all you need is the header section. The program adjusts for the number of Props in the system from the first entry in the spreadsheet.
All you need to do is include your .spin programs all in the same directory and everything is managed for you during the download with just one USB connection.
This is a Labview version but I would like to do the same thing in Python using the Propellent.dll.
Or, maybe the author of the Propeller Tool v1.3.2 would include this programming strategy right into it.
Regards,
sm