Advanced Search

Thank you for the help. I do appreciate it.

In case it helps anyone else willing to give me a hand diagnosing this issue, I've attached my .ini configuration file.

 

hope i did this right

Sorry had a family thing come up I'll post my files up in a min so I can get things checked over befor I power it up and not fry my stuff 

This is the so called "TB6600" with the TB67S109 chip, under 10$ and very good. Get these.

This is the original TB6600 with the TB6600 chip, ~15$ and usable but tend to die for no reason sometimes.

I never use ChatGPT.

It sucks.

The higher the frequency, the higher the power-to-mass ratio.

That's why high frequency switching power supplies are smaller and lighter than comparable line-frequency power supplies.

Those TB6600 modules sure seem like an awkward form factor, especially given you need 3 or 4 or 5 of 'em.

Sorry but i can not help as stated above, but i can move this to QtPyVCP section where the masters of Probe Basic reside.




This is a Qtvcp screen so it's in the right place.

More things I learned today, about Grbl:

Say you start a jog, and realize you meant to go the other way, and select the other direction. In LinuxCNC, this Just Works. Using Grbl, first the errant jog has to finish, and only then the next queued jog is executed. Not terribly efficient.

If you try and start a jog that would take the axis too far, you get an error. To clear that error, you need to go to a different tab (I'm using UGS), clear it, then go back to the jogging tab. It may be that there's a way to have both displayed all the time, but even then, having to specifically clear an error from a jog that never happened, seems... difficult.

I'd only started using it recently in LinuxCNC, but I found out today that neither Grbl (not surprising) nor FluidNC (surprising) supports the R parameter to G10 L2/L20. R lets you specify rotation, which can be very handy in cases where it's easier to get your hold-down clamps set securely if you rotate the stock.

This was helpful. I may be misunderstanding the language used here. Is this Offsets table supposed to be the coordinates of each work offset? If so, then it's not populating correctly and not updating when I set coordinate zeros using the gui at the bottom of the image. Am I interpreting this correctly? And if so, do you have any idea as to how I get the gui to talk to this table? It's not clear to me where it's saved. The preferences files I've looked in don't seem to have the necessary information.



 

No problem - thank you!

Love FreeCAD, apart from one little annoying issue.
Used the CAM for making the brackets and nubbins for the Franken Myford CNC conversion. It's my Goto for anything I need to 3D print, even used to help my son with some prototyping ideas when he was doing the additive manufacturing module at Uni.

AliExpress has carrier boards for the little step stick drivers, less than a dollar a pop. You would just need to make some cables with female DuPont connectors at one end and bootlace ferrules at the other, far better than bare wires. That's the setup I use for testing things rather than messing with the mill in the garage.

See the light blue star on your screenshot?
That is active offsets.
In Axis GUI you can choose to show offsets, i do not use Probe Basic so i do not know how to show them.

Standard would be the normal TB6600 and above up to huge servo drives, self contained in a box for each axis.
The 3D printer ones or step sticks are ... well for 3D printers, useless without their respective boards, very prone to interference, and some will just fail by touching them at certain conditions. Yes, TMC are pretty good, but using stealth chop or another such feature (forgot the name) is clearly stated to cause small positioning errors, so for anything vaguely precise should be avoided or used without those features active.
As luck would have it, there are step sticks with TB67S109 chips, i have some, found out i never need to push 3.5A on a 3D printer!

I don't follow. I have no offsets in use.

I don't have homing switches on this machine, it homes off absolute encoders from the servos. But I don't see why that matters here? The machine is homed and G53 is properly referenced to all the axis limits. The work envelope displayed is correct, as is the location of the tool within the work envelope. G54 is my work offset and is in an arbitrary position in the center of my work envelope (middle of the air here for testing code). The code I loaded is being mapped onto the G53 origin rather than the G54 origin that the code is calling and the machine has active.

Code should always respect the correct origin called, G54 in this case.