Advanced Search

Use it?
Use the hal file from here as starting point to get the servos going.
github.com/dbraun1981/hal-cia402/tree/main/example
 

You have not solved anything. If you want to use cia402 devices and the component, you need to read all at the beginning of the servo thread and write all at the end of it.

My thought is you have blindly copied a config. This is not plug and play, you need to build a config to suite your devices.

jimboh2 wrote:

Thanks rodw, I had ordered a DM542 from Steppersonline and it arrived today. Even with the 24v and 270OZ stepper and DM542 set at 3A I now have plenty of torque. Problem solved. I guess the TB6600s weren't up to the task.
Great to hear. I really don't know why people ever recommend TB6600's. They have been known to be cr@p for years.

There is more on the table yet! Have a look at the green and red lines here showing the torque difference between 24v and 48v for a 3.2 amp nema 23 stepper
www.moonsindustries.com/p/nema-23-standa...0-000004611110011244
 

The temperature rise was a max of 60 deg C (40 deg in the graph) so still at a very safe level.

They are from the same author but 'versa-probe' has not seen any updates for a number of years.
If you are using 2.9 then you should probably use 'probe_screen_v2.9'

seems that you are mixing underscore with hyphen in the hal

sauter_us. VS sauter-us

please forgive my stupidity.
after compiling I should have done the next step too I now see:
sudo halcompile --install --userspace sauter.comp

This seems to get me a bit further into debugging.
I get a Pin 'sauter_us_toolchange' does not exist error, which I don't understand yet.
as I did initiate it in the main hal file:
net tool-change iocontrol.0.tool-change => sauter_us_toolchange

 
Anyone has a clue of what I might be doing wrong?


 

here:

 

i cannot replicate, i get the value stored in both the var and the ui even through multiple restarts it remains correct.

I blame things I can't say but also the things I can't say with their fascination with American culture.
If you can't laugh at yourself you're coward.

Okay, good deal.  Glad it's working for you.

Thanks for the response. I am getting the line you asked about in the terminal. When I just tried using the space bar pause, it worked in all but one instance. I think you're right, it's a focus issue. In one instance, I had clicked the coolant button and then hit the space bar and the program failed to pause, but I was unable to replicate the behavior in the short session I had to test it this evening. I'll follow up if I'm able to reproduce the failure to pause.

But anyways, thanks for the help with this! I hadn't realized how much I use this feature until I didn't have it. When the tool is plunging rapidly, it's really nice being able to reflexively pause everything to check positions and the distance to go.

If you run linuxcnc from a terminal, do you see this text?
'Custom subclassed handler loaded for spacebar pause'

sometimes it's a focus problem, try pressing the 'G54' or 'ABS' button (after the program is started.). If that works I will look into why you need to do that.

I was able to reproduce this error with a simple test setup
with no mechanics and using g76. It also causes errors even
at a constant spindle speed, as the offset changes with thread
depth over the multiple threading passes which would cause
a  wider than expected cut.

To test this I setup a 7I96S with a stepgen spindle setup to
emulate a 8 count encoder with index (using the stepgen table mode)

I checked the offset by using the sum2 component to scale the spindle
rotations to the thread pitch and subtract the result. This offset
should be independent of spindle speed, X,Z motion constraints
and drive line distance to thread pass, but it is not.

Have you raised an issue on the LinuxCNC github page?
 

I would check the encoder signals at the Mesa card

The way to check is disable the drives (I hope this can be done
in a way the encoders still work) and then measure the differential voltage
(from A to /A and B to /B ) with a voltmeter in all quadrature states.
(you can usually to this by wiggling the motor shaft a bit to get all 4 states)

The absolute value of the differential voltage should always be greater than 2V
(you should get a positive differential voltage in one state and a negative voltage in
the other state)

Another check is to enable quadrature error checking on the encoder and seeing if
you get errors, that is set

hm2_CARD.0.encoder.NN.quad-error-enable
 true in halshow
and monitor
hm2_CARD.0.encoder.NN.quad-error

(CARD is the mesa card name and NN is the encoder number)

 

It doesn't seem to be working. Do I need to call that python file somewhere?