Advanced Search

Try searching for "rugbot" it does the same turning about the Z axis, but makes rugs.

You have my condolences.  I can't image.

I've attached the file.

In the meantime, I have changed my remap to Python. I still use the meaure_tool_inch.ng to measure tools.  I then compare that measurement to what I get when I manually measure the tool to check the accuracy.
 
John
 

Thanks Andy!

I'll give it a go.

ContinenteCNC wrote:

How is this information stored in kernel? Is it hardcoded?

LinuxCNC works with the parport_pc kernel driver. (previous to this you had to blacklist parport_pc).
This means that you can refer to parport0 and parport1, as enumerated by parport_pc, though I am not sure that many do. 

So the problem is somewhere in parport_pc. 

github.com/torvalds/linux/blob/master/dr...parport/parport_pc.c (maybe)

I have one more question about this issue recognizing Sunix cards.

So, let's assume these cards are not being automatically recognized as parallel ports because they are not listed as such in kernel.

How is this information stored in kernel? Is it hardcoded?

I know this isn't a issue that deservs so much talk, but if all it takes is someone to code it and ask a pull request to kernel I would love to do this work.

There are also some cards that load parport_serial driver instead of parport_pc. If this is the case I think that would be a coding I could do.

Again, not a big of a deal, but I would like to help and this seem to match my skills.

That's the go.

vre wrote:

All these CAM are dragknife not tangential.
Tangential knife has an extra C axis that is mounted on Z axis to actively rotate the knife.

Oh sorry I wasn't aware of the difference.

The Axis interface hides the spindle buttons if it doesn't see certain connections in the HAL file:

github.com/LinuxCNC/linuxcnc/blob/master...cripts/axis.py#L4201

The 0V, 5V and 12V pins highlighted look like test points to me. I wouldn't expect them to be scattered about the board like that if they were power inputs.

Nope, this one got away ... for now!

I think that this is probably a built-in assumption in the code.

The canned cycles really expect to be used in X and Y with Z as the drill, and that can only ever drill in the negative Z direction.

If you use this a lot then it might be worth looking at building your own "canned cycle" by using G-code remapping.

Or if you really want to distract yourself from getting the job done, you could look at fixing the source code and submitting a fix. (but discuss it first, so there is agreement on what a fix would look like)

github.com/LinuxCNC/linuxcnc/blob/master...nterp_cycles.cc#L110

You restrained yourself from converting it to Plasmac while they weren't looking, then?

Encoder_ratio is coded to count A/B phases (in software) from two encoders and to output a difference to drive a PID.
It would potentially be rather useful for a parallel port based machine, or maybe a Pi using GPIO. I expect it is fast and efficient, as it needs to do very little calculation.
But on systems where the positions are already calculated, you really can do it more simply with HAL maths functions (or the custom comp that my hobber uses)

To be honest, it doesn't really matter where Z home is. You can't rely on limits to avoid mashing the tool into the chuck anyway. (consider long boring bars....)
However, if you fitted a hard-stop for the tailstock, perhaps that would help with repeatability on occasions when you leave work in the machine with it powered down.

Maybe:
"If this message annoys you, add --nocheck to the loadrt hal_parport line"