Setting option system spi might help - see manual

Well just flashed another zero into a pico, loaded in the code and got the same error failing at the same point as before.

PIO init machine 1,0,f,p0,e0,s0,0

Bryan

Comment out both


These are defaults that MMEDIT has on a blank program.
The program you are running does not use these options, actually it fails with these 2 options.

Volhout

  Volhout said  

Bryan

Comment out both

'OPTION EXPLICIT
'OPTION DEFAULT NONE

These are defaults that MMEDIT has on a blank program.
The program you are running does not use these options, actually it fails with these 2 options.

Volhout

Just came down to the house and brought that second pico down and deleted both of options, reloaded the code and now it looks like I'm headed back to the shed to hook this up to a DM556 and see if I get movement as the code was spitting out numbers  

Regards Bryan

Bryan,

Please be aware, the DM556 uses 5V or higher signals. PicoMite is 3.3V, so you need to attenuate the signals, or use an optocoupler.



 

Volhout

Well mate only took about 10 minutes to hook this up and I hooked the Y axis and although silly me forgot about the 3.3 volts output we have life in my cnc at last as the Y axis WAS turning nice and slowly and quiet as.

So yes a 5 volt rail needs to be made and got a heap of small transistors to use. So tomorrow is another day where hopefully more steps are made.

Regards Bryan

Edit: just got an email and that GLBRL board will here tomorrow and also that external jogging board which will come in real handy for calibrating each axis.
Edited 2024-08-27 18:30 by Bryan1

The inputs are already opto isolated. You could probably interface 3V3 to it pretty simply.

Open drain MOSFET directly off the Pico. Connect the + inputs to 5V and the - inputs to the drains of the MOSFETs. You can also use NPN transistors, but use a 1K base resistor.

.
Edited 2024-08-27 20:32 by Mixtel90

Or a 4.7k/10k voltage divider. Will make 3.3V from 5V.
But this will only work if Bryan has both "-" pins wired together (to GROUND).

Volhout
Edited 2024-08-27 21:07 by Volhout

Eh? Isn't the Pico driving the stepper? Have I got it wrong again? lol

When I originally set it up for the CMM2 I pulled up to 5 volts and as I made the wiring already just swapped it over to ground on the inputs for the DM556. At first I thought it wasn't working then when I put my hand on the ball screw it was turning.

So yes the pico's GP0 and GP1 were connected directly to the DM556 the pico was running the stepper.

Huh,

The pico is NOT intended to drive the stepper with this software. You must have configured the test mode, where MMBasic generates stepper pulses, just to test the PIO.

To prevent pico driving the stepper change

to


The thread is about PIO reading stepper motor driver control signals. PhenixRising wanted to use this function to connect CNC software that is only supporting stepper motors, to drive servo motors.

So this software is NOT intended to drive the stepper motor. There is more advanced software to do that. Such as MACH3, MACH4.

Volhout
Edited 2024-08-27 23:24 by Volhout

  Volhout said  

Such as MACH3, MACH4.
Volhout

In fact, there are many machinists wanting to upgrade their machines with the likes of MACH3, MACH4 and other software packages that only generate pulse & direction.

However, many of these machines are already equipped with high-performance servo motors and drives that accept the industry-standard +/-10v motor command and these motors have encoder feedback for precise velocity and position control.

They don't want to replace perfectly good motors and drives and certainly not for lower-performing stepper-motors.

So, instead of this software sending pulse & direction signals to the stepper-motor drivers, the pulses are accumulated in the PicoMite which then becomes the "command" that feeds the PID loop.

So, if the control software issues a command of say 20,000 pulses, the PID would take that as a command to move 20,000 encoder counts or whatever the ratio is, depending on the encoder resolution. PID would output the appropriate analogue voltage according to the Proportional, Integral and Derivative gains. No more lost pulses and much higher performance.

  PhenixRising said  

So, instead of this software sending pulse & direction signals to the stepper-motor drivers, the pulses are accumulated in the PicoMite which then becomes the "command" that feeds the PID loop.

Is the Pico closing the loop? It receives the commanded position, in the form of steps and dir, from something else, and generates the +-10V to move the motor so the encoder matches the step count? Is there need for much precision in the +-10V signal? How many axes per pico?

Hi Vegipete,

It is to Phenix to tell, but I think the plan is that pico can convert 4 axis.
The PIO's can count 4 STEP signals inteded for stepper motors.
The second PIO can decode 4 quadrature encoders.

You need to drive 4 DAC's (could be SPI -or- PWM) and run 4 PID's.

With the speeds mentioned (10ms loop) pico could do that.

What I am unclear about is the way this should work. Typically stepper motors do not have any kind of feedback loop. So you just send them pulses. To get any performance out of them you have to ramp up and ramp down the speed carefully.

When you use these same STEP signals, your high performance SERVO system is degraded to stepper motor speeds. You can "speed up" the stepper motor signals, and remove the ramp up, but how does the CNC software know your servo has reached it's end point ?
Similar if you want to mill diagonal lines. 2 channels have to move position in close relation. With stepper motors that is easy. But can this be done with 2 servo's when they are running from the STEP signals ?
I just have not enough experience with CNC to know. I have to rely on Phenix. I hope he sends a video of the system in operation, so I have an idea how this works.

Volhout

Harm for well over 10 years my homemade cnc has sat idle and the fact this test code actually ran the ballscrew gave me that warm feeling that we are onto something. Now with using ballscrews there is NO backlash so it's case of counting pulses to say lets move 0.01mm then 1mm etc to establish the count for movement.

Phenix in another thread has already put up the code for ramping up and ramping down so lets say it takes 236 pulses to move 0.1mm then that 236 can be used as the base for the actual movement required etc.

In my cnc thread on this forum is plenty of pictures of my cnc and once I can get the movement all sorted I will go look for a new spindle drive as that small one I have just won't cut the mustard.

As this trial is still all setup this morning I'll measure the speed of the ballscrew so a figure for the frequency to speed can be established.

Regards Bryan

It's actually laughably simple, a heck of a lot easier than driving a stepper motor.

This is all about sampling, aka: discretized (the much-lauded "Arduino PID Library", it has to be said, is flat wrong  )

First question: Does Settick provide good-enough determinism...Yes it does. Just don't do anything interrupt-blocking, outside the ISR.

Choosing a sampling period:
There are endless write-ups about PID, all based on sampling but rarely is the sampling period discussed.

It's all about mechanical time-constants, machine bandwidth, etc.

The theory is that; the sampling-rate should 5 to 10 times faster than the time taken for the motor to reach 63.2% of maximum speed.

For example, I have a linear axis, here and it's maximum velocity is 1000mm/sec. I just happen to have my PID in a "Settick 4" (4ms).
So 10 X 4ms = 40ms and 63.2% of 1000mm/sec is 632mm/sec. This is overkill because there's no-way that I can accelerate to 632mm/sec in 40ms. Even 120ms would be too stressful for the mechanical components.

Even the RP2040 can handle a PID in a "Settick 1" (1ms) because execution time is only a few hundred microseconds. This 1KHz has become the industry-standard for high-performance motion controllers. It is the default of LinuxCNC, Galil, Trios, etc.
So if the application involves tiny, fast-responding motors and little inertia, 1KHz should be more than enough.

A single RP2350, reasonably overclocked can handle 4-axes @500Hz (2ms) and have plenty of time for calcs and comms, etc.
This is using an external SPI DAC because writing to the PWM adds >1ms to loop execution time. For most machinery, 500Hz is more than fast enough and so this will probably become my standard.

The stepper-to-servo system is a no-brainer because the velocity profiling is provided by the stepper controller. The PicoMite simply samples the step-count and applies it to the PID, each sample period.

In my own case, I am doing full-blown motion control:

Command position (encoder counts)
Acceleration (encoder counts/sec/sec)
Velocity (encoder counts/sec)
Deceleration (encoder counts/sec/sec)

The PID is enhanced to include; zero-offset, acceleration/velocity-feedforward and torque-limiting

The integral (I-term) has an anti-windup limit.

For test purposes, I update the velocity profile for each PID sample whereas most controllers might only update the profile every 2-10 samples.

The RP2350 @378MHz, running all of the above, peaks at ~350 microseconds.

Servo-motors are a piece-of-cake but servo-hydraulics can be quite a challenge. Having a PID, running in an interpreter and being able to perform "tricks" at the sample-level, makes life so much easier.

But beyond this, we have the added bonus of multiple encoders.
I am a proponent of dual-loop feedback. IMO, the industry has gone backwards because servomotors now have their position-feedback, fixed to the motor-shaft.
This only provides the angle of motor rotation and is great for stability....but what about the important bit...the actual load?
We now have the option to utilize the motor's feedback device for the D-term (velocity damping/stability) and a load-mounted feedback device for the P&I (position) terms. Happy days.

Motor command:
I am using a 12bit DAC. There's not much point in having a higher resolution because the servo-drive's analogue input only resolves to 12bits.

I'll post code and videos in due course (waiting for my proprietary Yaskawa USB cable right now)
Edited 2024-08-28 17:18 by PhenixRising

G'day Guy's,
           Well I have been reading the manual and also read that PIO manual aswell, now on reading the PIO manual you guy's were measuring the frequency using GP7 so I have tried

SETPIN (GP7), CIN
 
PRINT (GP7)

But I keep getting the error

> run
[101] SetPin (GP7), cin
Error : Pin 0/NULL is reserved on startup
>

While I have this all setup it would be great to count the pulses to verify the stepper and leadscrew.

Now the leadscrew hs a 5mm pitch and the stepper has a 2 degree step, so

5/180 = 0.0277777777777778 so have a 0.028mm step resolution.

Try:-
SETPIN GP7, CIN
Pause 1000
PRINT Pin(GP7)
Edited 2024-08-30 12:01 by phil99

  phil99 said  

Try:-
SETPIN GP7, CIN
Pause 1000
PRINT Pin(GP7)

Hi Phill just tried that and still got the the same error come up so I'm thinking it could be the placement in the code.

 do
  a$=inkey$                                     'just for control
 
  'get the data from the fifo
  pio read 1,0,5,dat%()                         'read whole fifo
  posi%=dat%(4)                                  'last data in fifo
  if posi%>2147483647 then inc posi%,-4294967296 '2'th complement
  'print posi%                                   'show position
  setpin(GP7), cin
  Pause 1000
  print pin(GP7)
  'just some pause
  pause 100                                     'any delay needed
 
is where I put the setpin so I don't know if that is the issue.

SetPin remains in force until there is a corresponding SetPin GPx, Off so you only need to do it once near the start of the the program, before the Do Loop. Don't use brackets in the SetPin command.

Adjust Pause 1000 to whatever count accumulation time you want.

You can reset or pre-set the count to any value with:-
Pin(GP7) = 0 'or any value
.
Edited 2024-08-30 13:31 by phil99