Advanced Search

Since I was able to create a usable tool changer control comp with the coding assistance of AI, I figured I had better confront the final boss beast of this CNC conversion... the spindle control. I was already crastinating on this before I turned pro.

If you remember, I retained the original motor, CVT and back gear, and added a VFD instead of the Dahlander motor winding switching. So far I was just manually controlling the back gear and CVT, and guessing what VFD frequency to command, with a single ratio hard coded on the INI, which is roughing right for about 1000 rpm.

I want to believe that I can use a comp to have the system follow S commands, including for CSS cuts.

 

So I have:
- huge variation in inertia, requiring PI gain scheduling based on overall reduction ratio
- no feedback of CVT or back gear position, which lead to the attempt to infer gear ratio from spindle encoder / analog motor speed command.

I got it sort of working with the assistance of ChatGPT(free) for coding. However, the need to freeze the ratio calculation during CVT bumps, or commanded speed changes means it very laggy, with speed corrections happening long into cuts. 

I have attached the ChatGPT created comp and hal, for general interest...
... continued next post, to separate the ChatGPT attachments from the Antropic AI generated files.
 

I had a quick look at the PortingPlan.md. Am I right to presume that this was AI assisted coding? It's insane how this thing is a game changer for non coder; I have some understanding of coding, read a lot of source code, but am not able to write more than a couple of functions to adapt an existing code (and even that part is mainly copy-pasting form existing libraries). Yet, within three days had a CANopen motor connected to a RPi spinning smoothly in CSP mode. I wouldn't say with Claude-code's help, but rather than Claude-code had it working with some of my contribution for hradware connection and debugging. 

Back to the topic, I think that eraserhd is one the right path when trying to generate pulse from PIO. Guess that's just a prompt more for the RP2350-(not PIO as it was there for Platform-IO, right?). The stepper-ninja  for LCNC claims a 1MHz per channel step generator using PIO.

Cheers

Thank you very much. Is there anything else that can be damaged down the line? I mean the DAC? 
 

Hi,From few month program SIM (not on the CNC) are stucking before controled movement (not G0). By chance, I have fond that reducing spindle speed unlock the program.
I take a look a the HAL configuration and check some values with HalShow. Starting from spindle-speed-cmd to spindle-at-speed, There is a calculation error between sim_encoder_0.speed input pin and encoder_0.velocity output pin.

Attached a calc file with some values of tested values
Version info : LCNC 2.9.8 Run In Place SIM on LinuxMint 22.3 (6.8.0-117-generic

I just tried increasing D and it seemed to increase the amplitude of the oscillation as I increased the value. 

I also wanted to verify the encoder is working correctly even though it appears to be working correctly in halscope. I hooked it up to an oscilloscope and got a chart I wasn't expecting. Channel A seems to be stopping at 0V on both the rising and following edge. channel B seems correct and bounced between +5V and -5V.

Would this cause any issues with counting on the mesa card?

cbaugher has shared is RP2035 version which used remora-core. A really neat implementation that has both ethernet and spi communication options. Uses PIO for the SPI and hardware QEI (Quadrature Encoder Interface).

github.com/cbaugher/Remora-RP2350-PIO/tree/main

Hard t tell but it does look the the velocity loop is unstabley

Just as a test have you tried adding some D term to the PID?

It was originally set up with a virtual tach signal coming from the Fanuc controller. The original manuals showed a tach voltage of 3V/1000RPM which I should have. I ran the motor on a bench power supply, bypassed the drive, calculated the motor speed with an oscilloscope connected to one of the encoder pins, then measured the output voltage on analogout3. my output seems to be scaled correctly and the voltages match the original drive documentation.

I believe I have the scaling and direction correct, but am wondering if I am running into some type of resonance between the virtual tach and commanded velocity.

Does that seem possible or correct?

Method 34 is using only the Z pulse of the encoder, no homing sensor is needed for this homing method.
The homing sensor is connected to any of the digitals input pins of the drive. It is not assigned by default, i. e. it is configurable.
I just tested homing using a homing sensor with homing method 19. But still, the drive behaves the same way as in the video - starts looking for the sensor at high velocity, when rising edge is triggerred the motors reverse at slow velocity, when falling edge is triggered the motor starts moving quite fast and position deviation errkr is triggered.

Did you connect the origin switch to the servo?
It's usually called the HOME switch.
The VECON manual is really terrible.
It doesn't say anywhere where to connect the limit switches and the origin (home) switch.

@leandrocontarini Could you share the bit files you are using?

The original part was a NE5230, which is now obsolete, a suitable replacement is a THS4281D or a OPA197IDR
 

I achieved some kind of success in homing the servo motors using the CiA402 home component. There is still a problem when the homing is executed in a certain situation. Basically, I am using homing method 34. Then using the halshow I set  the 'request-custom-homing' pin, the homing procedure starts but when the servo find its Z pulse it start moving quite fast. Perhaps it tries to reach a certain position but LinuxCNC reports 'joint 0 amplifier fault' and the servo drive error is 'Position deviation is too large'. You can see videos of what is happening - one video in normal velocity and one in slow motion.  Videos
This behavior of the drives can be observed the the actual position is above 35 000 000 pulses. When the homing is started below this pulse number, the motor finds it Z pulse and the move quite fast to the position where the homing was started.
Attached are the configuration files.

Moved to "QtPyVCP" section.

Did you find anyone to help?
If not, post some pictures here, we are quite good at figuring out things from pictures and videos.
Also some pictures of the insides of control box would help a lot.