Advanced Search

Totally agree mate.
One thing I would like to add, is carefully read the dialogs in the installer.
99% of the time when things don't work the issue is with the user.
Tho I still have my doubts....

I seem to have different pins than listed in the tutorial you linked. I've attached a screenshot below of the pins that i have available to  me. This was sort of the same issue i was having with the guide i found and was trying to follow. any idea where i can find these pins and start turning??

Thanks a lot for your answer. Sorry for replying so late.
I really find it quite remarkable that noone tries to drill with a tailstock axis!

I ran into the problem, that the used functions in the linuxcnc-turn post aren't well documented at all and at the same time use quite old standarts. I didn't found a way to change the axis-letter for G0 commands. I could change the axis-letter of the drilling-cycle itself but then still have to approch-move and rapids on the wrong axis-letter. Because the rapids are all handeled the same way, it would affect all gcode-moves if the letter is changed. Also this post doesn't support custom geometry.
I also did not find a way to make it work with W. Also i use rigid-tapping on this axis and thus cannot usw the axis as W(W doesn't support spindle-synchronous-moves).
In a nutshell I just need the information parsed to the post from the cam to include the right axis in the first place. But I am also open to any other ideas!

Best regards Tim

But what settings have you entered? I have max current, standby current and closed loop/open loop. Everything else is default.

I realize my method is a temporary fix. Maybe I can look into that now when things work fine. On the other hand, if it works it works.

I have homing on traditional limit switches. Seems to work so I am happy.
 

Hi all,
If I call an M6T2 in MDI, linuxCNC seems to just wait for something that never occurs. I can hit escape to cancel it. Afterwards, I notice that the O-word tool change sub is loaded as the active program to be executed. No alarms or aborts appeared.
Is there something I should look for in halshow to help diagnose this?

My remap uses the standard-glue prolog and epilog with no changes.
For a tool changer as explained in the following is that okay? Do I need to make changes?

This is a standard carousel style tool changer. Powered by an ac-motor with a sensor for index and pocket alignment. It uses pneumatics to go under the spindle or park.

I have looped the iocontrol signal as stated in the remap extended manual.
net tool-change-loop iocontrol.0.tool-change iocontrol.0.tool-changed
Were there other signals that I needed to loop?
Do I need to do a tool prepare remap for an M6 remap to work?


Other Info that might be helpful to explain some of the lines in the toolchange.ngc file:
The spindle has 3 proximity sensors to tell if the spindle is empty, draw-bar is engaged, or if the spindle is full.

Thank you for your time,
This is a confusing one for me.

You've just killed my initial excitement, Tommy:)

Still wondering if 1500x1000mm work area is too big for HTD3M 20mm wide belts driving ultra light assembly. My concern was more on control side:) I'm not familiar with compiling custom kinematics.

With your help PCW and RODW I had a major learning curve. Big thanks for your help! Works like a charm now!

JT

No it's not possible to make a copy of controls. What you can do for things like power and E Stop is to have them on the main part of the QMainWindow so it's always visible.

You can see in this sample that the top frame that contains the estop, power, run and quit buttons is always visible no matter what tab you select because they are in the tool bar. Also the DRO and Information box are always visible in this example. It does have duplicate run buttons as it's an example and the upper ones are menu items so they can also be in the tool bar.


JT

It's kind of funny that you're having exactly the same problem as me.
You seem to have almost the same configuration as me and also the same name
And you also seem to be using the M600 routine to probe the TooTall18T.

I can't quite figure it out at the moment, but every now and then I have a file that can be read in without an error message.
The most annoying thing for me with this error message is that nothing is displayed in the visualization and so I have no idea what the machine is doing until it does it.

I'm curious to see if you get any further here.
If I find out anything, I'll post it here.
Greetings Jens

Strange, I have never had that issue. Recently after a long holiday without touching it, I could not get it to move at all and it made awful sounds.
I fixed this by resetting to factory defaults (0x10110) by changing the values in the XML on sucessuve restarts. Now its perfect so I want to work on homing,
The only following error I had on my Mill with ECT86 drives was when I had the accelleration too high and it would do that coming out of homing. I decided this was probably because the accelleration (well decelleration here) was too high and the setting was overcome by inertia. Reducug accelleration in the ini file fixed it.

You need to make sure you have the latest subroutines files also

Should work, but I'll make an image and try and will let you know what works (not).

Gpu works?