Advanced Search

I guess the H11L1SM optocoupler could be damaged but that's
much less likely as it does not connect to the outside world.

I'm at this step to. But I feel like it's been worse after the autotune than it was before.
That software is such a mess that I regret not going the Leadshine way.
I also have a slightly noisy Z axis servo but I can't find the gain parameter... Any clue ?

Mark I thought about your issue some more and I have a  solution. Not terribly invasive a little bit of work but saves the variator. 

Return the speed control pid tuning to linux cnc

Put a closed loop stepper motor on the variator. Here's why

1. step counts are easy targets, so 10 steps = 1 point of gear ratio for example.

2. build a table of Frequency from command to stepper that optimizes torque.

So on Y you have commanded input from Lcnc as frequency
on X you have steps iun the table itself you have gear ratios. Build you selector logic to Always shoot for best torque.




Speed Command from g code
encoder feedback
min max home positions.
then spindle at speed output.

the look up table doesn;t even have to be complex could just be along switch statement, if <200 && >300 spnd cmd gear = 4

that's it. then let linuxcnc handle the fine control. your just grabbing the spnd cmd speed and setting the ratio.

See attached

www.alibaba.com/pla/IHSS57-36-20-Nema23-...rGX0_eUaArgzEALw_wcB


 

Good Day

Does anyone know how to re-install GPlus 450 software on a Knuth Mark Super CNC running windows XP SP3
On the Gplus 450 software my machine type is not even listed
Got all the Settings Files and Software Licence No's

First time Round got this error Message (Attached Jpg - Licence Install problem) 

Controller does not want to connect to internet - So Cannot even get Online Help From Knuth Germany
Any advice would be Very Much Appreciated
Many Thanks
Otto 

… continued…

Not being able to improve on that version, I started over in  Anthropic AI (free). This has been less successful. It is a more complex solution, and have had more issues with stability, and the ratio calculation freezing.  

However what is very positive is how easy it has been to have it generating data logging and analysis files. With better data, hopefully I can make faster improvement.   

I think I will do one more attempt to control this without adding hardware.  I will go back to my original concept for this.  

Rather than trying to control the CVT closed loop off that dirty inferred gear ratio, just command it open loop, with fixed ratios. Considering the CVT as five discrete gear ratios, one second apart, I’ll do a a survey of the system to create a lookup table of VFD Hz, CVT “gear” position, back gear position verse spindle speed, overall gear ratio, P and I values. My idea being that on spindle start, it sets the gearbox, then accelerates to the VFD and CVT nearest defined speed in the table, open loop, and then the PI closes the loop to control the VFD to control to that speed. Whenever the spindle is at a steady state long enough for the inferred ratio to become stable, the ratio inferred from commanded motor speed, could be used as a sanity check whether the CVT is still at approx the ratio expected.
Cheers,
Mark

Hi,

I am having the same problem, with the same controller , only 4 axis . Same id, and same symptoms. I am running linuxCNC 2.9.8, I have tried to change the ID in the .rules file, but no luck.
Did anyone resolve this, any suggestions?

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.