Getting interbus-like behaviour with a SPI peripheral is going to be challenging.
In your case, you need to emulate a 96 bit shift register.
Again, you think much too complicated. It's a lot easier. The master has two buffers, one for TX and one for RX each 6*12 = 72 bytes long.
Each slave has a ring buffer holding only 12 bytes implementing a FIFO queue. Even on the stupid ARM devices I think I could implement that with a DMA state machine so the processor doesn't have to feed the RX/TX registers.
It can be done even simpler. As a few more bytes of wasted memory doesn't cost anything theese days so I'd do it with linear buffers instead of ring buffers. This makes the DMA state machine easier. The picture shows the state of buffers and pointers before communication starts.
Every slave puts its output data at the beginning of its own linear buffer. Each slave has the write pointer 12 bytes ahead of the read pointer implementing a 12 byte FIFO.
The master starts communication and outputs 72*8=576 clock pulses. Data travels through the chain of buffers...
At the end, each slave has the input data from the master meant for him at the beginning of his buffer. He also has partially input data from the master and partially output data from other slaves in the rest of the buffer. He doesn't know the source or meaning of that data but it doesn't matter at all. All he has to do is pass that data further downward the chain while ignoring its contents.
The master gets output data of every slave in the RX buffer in reverse order.
I forgot to mention that the master has to place input data to the slaves also in reverse order in the TX buffer. Each slave has the input data in the last 12 bytes of the local buffer after communication has finished.
You could use the streamer in 1-bit mode to shift out data from hub RAM. If you placed your serial data into words with start and stop bits in position, you could send them all out with a single command.
Yes, I definitely have stop talking about theoretical stuff and learn how to program the P2 so I can make something real. I'll try to read the datasheet over the weekend so hopefully I'll be back with lots of questions next week for the webinar.
Sounds like an awful lot of bang for the buck, Nicolas... You obviously know your market but I would consider $500 to be a heck of a deal.
It's too early to talk about money. The $150 I mentioned is a theoretical goal. I don't know if it's possible. And it is for the components of the PCB, only. It does not include motors, encoders, cables, casing and connectors nor does it assembly and testing cost and not to forget profit. So the end user price will be much higher than $500. But I think even $1000 for a plug-and-play system including say three 400W servos and one 1.5kW spindle would be a great deal.
But price is not the most important thing. The problem with all cheap CNC systems is that they are either unsafe or unusable. I mean if you want to protect the operator from injury from a potentially dangerous machine with rotating cutters and enough power to smash or rip your arm off you have to add safety doors. With chinese drives all you can do is to cut power to the drives when the door switch is open. But this means that, first, you can't move the axes while the door is open, and second, you loose position and have to do a homing procedure again after the door is closed.
The key with an all-in-one controller is that the encoders are connected to the main CPU and not to the motor drive only. The CPU is not shut down while doors are open and can keep tracking position. The idea is not new. There are existing industrial drives and controller offering this (Beckhoff with EtherCat for example), but they usually cost >$1000 per single axis.
DACs for what? I only need ADCs for current measurement, window comperators for overcurrent shutdown and PWMs to control 3 half bridges.
Worth checking if maybe a P2 could even make sense in those slaves too ?
The cordic solver is ideally suited to do park transformation for motor commutation, yes. But the P2 is way too expensive for that. It's at least $10 more expensive than a small ARM chip. That'd add $60 to the overall BOM cost. I try to keep total component cost <$150 if possible.
That would be a different story for a single axis servo. The P2 would be there anyway. I consider doing that as training project, first, to estimate what computing power is really needed per axis.
I also considered using a P1 as slave. But it lacks good ADC capabilities. The simple RC SD ADC has no auto calibration, is too noisy and drifts over temperature. External ADCs are too expensive.
In the case I haven't mentioned, the power stages run from rectified mains voltage (230Vac). Output current should be something like 4A continous for 5 axes (positioning) and 8A for the 6th (tool spindle).
Parallax plans on making cheaper cut-down P2s with fewer cogs, less RAM, and fewer I/O. Would they be a good fit for slaves?
The key with an all-in-one controller is that the encoders are connected to the main CPU and not to the motor drive only. The CPU is not shut down while doors are open and can keep tracking position. The idea is not new. There are existing industrial drives and controller offering this (Beckhoff with EtherCat for example), but they usually cost >$1000 per single axis.
I don't remember a drive that didn't have main power and auxiliary power. The aux power keeps the drive alive, including the motor's feedback system.
Parallax plans on making cheaper cut-down P2s with fewer cogs, less RAM, and fewer I/O. Would they be a good fit for slaves?
I'm sure those smaller versions are at least years from production....
I hope not too many years. Having smaller cheaper P2's will attract more potential users and those users will move up to the bigger versions once they need them for larger projects.
To get any cost reduction from a smaller P2 everything will need to be reduced...
4 Cores/Cogs
32+8 I/O with smartpins
256KB Hub RAM
2 Cores/Cogs
16+8 I/O with smartpins
128KB Hub RAM
And there is a hefty up front cost to Parallax, and it's way more than we thought.
And you are not going to see a 50% cost reduction as some things are fixed. Guess 30% at best.
I'm sure those smaller versions are at least years from production....
That's the problem. I have to do it now with what is available. If it works with the ARM chips then there's little motivation to re-engineer it without a significant advantage.
But anyway, I'll make a prototype for a single axis where the P2 does the analogue stuff and the park transformation (with cordic). So I can compare the performance. The cheap ARM processors don't have very good ADCs. They are 12 bit but have a lot of noise. I think I can get 10 bit accuracy for single samples and maybe 12 to 13 bit resolution with averaging over many samples.
Because some of you still seem not to believe my concerns about effects of jitter and non-continuity of velocity on surface quality I've attached a copy of the picture I wanted to show in an earlier post. The link didn't work for some reason.
Of course, everything depends on the machine. Most hobbyists have a machine with poor stiffness. Stepper motors are grunting and whining producing all sorts of vibrations. Underpowered motors and flexible support allow only moderate cutting speeds so that the cutter is more grinding than cuttting and so on... Many users don't know anything other than their own machine so they can't imagine that it can be done much better. The often stand with their mouth open when I show them that the majority of the problems are gone when I just exchange the controller producing the step signals.
To make a fair comparison you have to use the same machine, program and cutting parameters. The following picture shows two (theroretically identical) workpieces. The upper one was machined using EdingCNC, a CNC controller based on the core of LinuxCNC running on a Microchip CPU if I remember correctly. It does some sort of Bresenham-like algorithm as Mickster described with a fixed timeslice loop and whole numbered steps per timeslice.
The lower one was machined using my controller with the propeller. It uses the propeller counters with PHS and FRQ registers to produce steps that are not limited to a whole number per timeslice but can instead have arbitrary phase at time boundaries. This greatly reduces jitter. You can see the much better surface quality even though it uses the same imperfect machine with stepper motors.
Comments
Again, you think much too complicated. It's a lot easier. The master has two buffers, one for TX and one for RX each 6*12 = 72 bytes long.
Each slave has a ring buffer holding only 12 bytes implementing a FIFO queue. Even on the stupid ARM devices I think I could implement that with a DMA state machine so the processor doesn't have to feed the RX/TX registers.
Every slave puts its output data at the beginning of its own linear buffer. Each slave has the write pointer 12 bytes ahead of the read pointer implementing a 12 byte FIFO.
The master starts communication and outputs 72*8=576 clock pulses. Data travels through the chain of buffers...
At the end, each slave has the input data from the master meant for him at the beginning of his buffer. He also has partially input data from the master and partially output data from other slaves in the rest of the buffer. He doesn't know the source or meaning of that data but it doesn't matter at all. All he has to do is pass that data further downward the chain while ignoring its contents.
The master gets output data of every slave in the RX buffer in reverse order.
It's too early to talk about money. The $150 I mentioned is a theoretical goal. I don't know if it's possible. And it is for the components of the PCB, only. It does not include motors, encoders, cables, casing and connectors nor does it assembly and testing cost and not to forget profit. So the end user price will be much higher than $500. But I think even $1000 for a plug-and-play system including say three 400W servos and one 1.5kW spindle would be a great deal.
But price is not the most important thing. The problem with all cheap CNC systems is that they are either unsafe or unusable. I mean if you want to protect the operator from injury from a potentially dangerous machine with rotating cutters and enough power to smash or rip your arm off you have to add safety doors. With chinese drives all you can do is to cut power to the drives when the door switch is open. But this means that, first, you can't move the axes while the door is open, and second, you loose position and have to do a homing procedure again after the door is closed.
The key with an all-in-one controller is that the encoders are connected to the main CPU and not to the motor drive only. The CPU is not shut down while doors are open and can keep tracking position. The idea is not new. There are existing industrial drives and controller offering this (Beckhoff with EtherCat for example), but they usually cost >$1000 per single axis.
Parallax plans on making cheaper cut-down P2s with fewer cogs, less RAM, and fewer I/O. Would they be a good fit for slaves?
I don't remember a drive that didn't have main power and auxiliary power. The aux power keeps the drive alive, including the motor's feedback system.
I'm sure those smaller versions are at least years from production....
I hope not too many years. Having smaller cheaper P2's will attract more potential users and those users will move up to the bigger versions once they need them for larger projects.
Maybe adoption is swift and those lines are short.
4 Cores/Cogs
32+8 I/O with smartpins
256KB Hub RAM
2 Cores/Cogs
16+8 I/O with smartpins
128KB Hub RAM
And there is a hefty up front cost to Parallax, and it's way more than we thought.
And you are not going to see a 50% cost reduction as some things are fixed. Guess 30% at best.
That's the problem. I have to do it now with what is available. If it works with the ARM chips then there's little motivation to re-engineer it without a significant advantage.
But anyway, I'll make a prototype for a single axis where the P2 does the analogue stuff and the park transformation (with cordic). So I can compare the performance. The cheap ARM processors don't have very good ADCs. They are 12 bit but have a lot of noise. I think I can get 10 bit accuracy for single samples and maybe 12 to 13 bit resolution with averaging over many samples.
This is how it should be:
To make a fair comparison you have to use the same machine, program and cutting parameters. The following picture shows two (theroretically identical) workpieces. The upper one was machined using EdingCNC, a CNC controller based on the core of LinuxCNC running on a Microchip CPU if I remember correctly. It does some sort of Bresenham-like algorithm as Mickster described with a fixed timeslice loop and whole numbered steps per timeslice.
The lower one was machined using my controller with the propeller. It uses the propeller counters with PHS and FRQ registers to produce steps that are not limited to a whole number per timeslice but can instead have arbitrary phase at time boundaries. This greatly reduces jitter. You can see the much better surface quality even though it uses the same imperfect machine with stepper motors.
That makes selling your driver upgrades an easy choice