Advanced Search

It would help if you posted your Hal and ini files

I would first verify that your X,Y,Z directions are correct
(by jogging and watching the motion and position display)

Then you change the sign of the home search velocity if
its wrong
 

HOME_SEARCH_VEL = -10
 i.e. change the sign in the ini file to -ve or+ve
 

Don't know, cant duplicate it here.

Does any output cause the issue?
 

Nothing for this specific test

There are a couple things that concern me though which might help me choose between these types of breaks or the counterweight or gas spring breaks. I don't know if those Teknic breaks are as powerful as the other ones and maybe it doesn't matter, maybe they would be fine. 

They'll be fine.  You just pick the one that matches your frame and shaft sizes.

If you want to measure the z-weight, just put a kitchen scale on the router bed.  Let the Z-axis sit on the scale - maybe with a block between the spindle and scale - and that'll get you close enough if you go the counterwight/spring method.

The weight on the scale is not the force the brake has to hold; the brake just has to keep the screw from rotating - which is much less than the actual weight of the axis.  I bet you can hold it up with two fingers.

As Tommy indicated, all methods are some compromise.  Brakes add inertia to the rotating components and length to the servo assembly, counterweights add inertia to the whole moving mass, and gas springs - even constant-force types - can be fiddly to get the value and geometry right.

It all depends on what you feel more comfortable doing.

and how i do that?

That's the same as my test setup and same SW revision.

Is anything connected to the 7I73 I/O connectors?


 

all jumpers are down 

RotarySMP wrote:

Thanks for the offer. I just received a care package with three parting tool holders in it, so I should be good for the next two attempted parting moves :/

Yeah, I know, but I am on a welding trip at the moment.

I sympathize with your procrastination.

Assuming the ATC positions can handle both a stick tool and a drill/bore tool at the same time, getting the logic & data management sorted out for that ATC (and rear tool holder) is going to be a challenge with the 'stock' LCNC tool table.

Regarding the threading & swarf management... Maybe use a LH threading tool/insert and run the lathe in reverse.  i.e. cut a RH thread back to front and drag the swarf out.  (need a LH tool/insert so the helix angle is correct for the reversed motion)

It doesn't work quite as well if the spindle is going really fast or you have a steep thread since there isn't as much (or any) Z-axis lead-in to accelerate.  But for large, fine(ish) threads it works quite well, as does using the threading tool to cut a thread relief groove near the shoulder to give you a little accel room.

Yeah hehe, its weird.

I can upload my ini when im home, but im 100% sure everything is fine.
Just loaded an huge car doorpanel, did long ago and it worked just fine.

It gets even cooler.
If i set my machine to G54, the piece goes into the corner and clearly out of my workspace. BUT.... All numbers are fine.

I try to clear every G out of that Gcode and strip it naked. Lets see, what might happen then.

Why are you asking this question?

Because your initial issue in the video seems to be that the home search
direction was wrong, which indicates you did not set up the homing direction
correctly in pncconf.

How a start have you read about LinuxCNC homing?
- Yes I have read and partially understood the German manual 2.9.2 page 100 regarding this topic.
Why are you asking this question?
- How is the question and answer relevant to my main question?

The ini file constants listed in this homing document are adjustable in pncconf.
- Ok, do I have to assume that this is the case on the PcnConf X,Y and Z axis windows? If this is the case, I have not yet been able to test out the main hit and will probably have to go through a lot of trial and error?
- And what next?
- To what extent is the question and answer relevant to my main question?

Also, have you checked home/limit switch operation with halshow?
- Yes, I have. If by your comment you mean whether the PNP switches switch - then I may write to you as mentioned above in my last post that the axles can be moved by hand (not during the reference runs) and the sensors interrupt the run.

I would like to briefly ask/mention my thoughts on a procedure according to which I imagine checking all connections on the 7i76 first? Is this not the case?

Is it absolutely necessary for and with LinuxCNC and with 7i76 and 7i92 that certain steps have to be carried out first so that the next step can be taken at all, or is it possible that all actuators of the machine are first connected to the 7i76, checked and configured.

OP - you weren't being ignored.  I was just hoping someone smarter than me would chime in with a bullseye answer

Hopefully I'm not stating the obvious (or bad info), but I think it might be helpful to clarify where LCNC is storing tool/pocket info.

• 'Standard' LCNC stores tool number & pocket number in the tool.tbl file, and parameter 5400 is (I think) the current tool number. 
• Probe Basic stores the pocket number as parameter value and ignores the pocket number column in the tool table.
  • I believe this is because - while PB was being developed - LCNC treated the tool.tbl pocket number as the index of the table, not the actual pocket number when passing a value to a consuming function (carousel.comp).
    • i.e. the first entry in the table was pocket #1, regardless of the value in the pocket field.
  • LCNC Github is littered with a number of issues reporting the tool/pocket problem.  It was reported fixed, but I haven't personally tried a config (extensively) to see if LCNC is fixed yet.
  • github.com/LinuxCNC/linuxcnc/issues/400
• PB Devs worked around this bug/feature by creating additional persistent parameters in the linxcnc.vars file which represent the tool-pocket relationship and are used by the subroutines to store/retrieve tools.
  • Specifically, the additional parameters (#5190-#5207 in my case) represent the pockets.  The value written to that parameter represents the tool number corresponding with the tool.tbl tool # value.
  • PB does not use carousel.comp to manage the ATC.  The PB subroutines have internal shortest-path formula and M68/M64/M65/M66 statements to turn on/off outputs for ATC rotation.
• I don't know how PathPilot handles tool/pocket numbers, but since PP pre-dates some of the tool table edits which appear to have fixed the issue the Probe Basic devs worked around, I suspect Tormach uses some other method.
  • Maybe some python file magic?
  • If anyone has PP ATC files/macros/subroutine files I'd love to take a look at them and see how Tormach manages the tool-pocket relationship.

The reason I'm blabbering about the above is the OP will need to be aware that switching from Axis to PB (or PP) will likely require a significant change in the ATC subroutine choreography and data storage.

And... that setting up an ATC in Probe Basic using carousel.comp (like in Axis) will also require significant changes to the PB subroutines.  PB is designed around a geneva mechanism with relay-controlled (dumb) motors.  Using a stepper/servo to control the ATC means either

• incorporating carousel.comp in to the subroutines, or
• treating the ATC as an axis

There are examples of both 'non-stock' Probe Basic ATC schemes posted in the forum.

TLDR: pick your GUI first, then we can help you get an ATC sequence that works with that GUI.

Huh weird... It looks like all your x and y lines are in the bounds of the machine..... Are you sure their isn't a random line somewhere?

If not it's probably not fusion.

I'd check your ini file on your x and y axis max and min limits as well as the corresponding joints.

Feel free to post the file