Advanced Search

I've been working on using QtPlasmaC to control a fiber laser machine, and we've had a few threads going on over in the "Hardware & Machines  Plasma & Laser" forum. I'm sure many of you are in both places. We had a discussion over there that raised the idea of materials properties for fiber laser cutting, and I wanted to start a thread here as that discussion seems to make more sense here.

If it would make sense to add fiber laser-specific materials properties it appears to me it is not as simple as just adding the materials to github.com/LinuxCNC/linuxcnc/blob/master...qtplasmac_handler.py. There are other things like the qtplasmac-materials converter and magic comments that depend on the current specific schema for materials. So it definitely should not be done lightly as it could quickly become a maintenance burden for marginal benefits.

I believe the current plasma material properties are:

• PIERCE_HEIGHT
• PIERCE_DELAY
• CUT_HEIGHT
• CUT_SPEED
• NAME
• KERF_WIDTH
• THC
• PUDDLE_JUMP_HEIGHT
• PUDDLE_JUMP_DELAY
• CUT_AMPS
• CUT_VOLTS
• PAUSE_AT_END
• GAS_PRESSURE
• CUT_MODE

I am currently repurposing CUT_AMPS as laser power 0-100% and that seems to work fine. I also actively use PIERCE_HEIGHT, PIERCE_DELAY, CUT_HEIGHT, CUT_SPEED, NAME, and KERF_WIDTH for their intended uses. I can see a potential to use GAS_PRESSURE for an actual gas pressure. Beyond that, I could see the utility of:

GAS_TYPE to choose e.g. O2, Air, or N2
FOCUS_HEIGHT if there are machines that have a motor-driven manual focus
and some sort of NOTES might be helpful to store the nozzle type, but since that might be useful for Plasma as well and does not exist maybe people keep track of that separately?

So for my current purposes I don't need any different material properties. But even in the long run, ignoring something like NOTES, fiber lasers could use CUT_VOLTS for FOCUS_HEIGHT. This leaves just a GAS_TYPE which is probably an edge case to automate within a machine.

I'm no fiber laser cutting expert, but I am wondering if there are people on here that understand the universe of potential materials properties better that could confirm that is all would be needed to effectively support operationalized fiber laser cutting.

If that is the case from my perspective I don't know if it would be worth the effort to add laser-specific properties. The juice might not be worth the squeeze. But I am interested in the diverse perspectives of the wise folks on this list.

I do think it might be worth considering adding a handful of generic custom properties to materials that would allow free-form handling of whatever custom material properties might be needed in the future. This could allow storing things like nozzle notes, gas type, etc. with the machine integrator making use of the custom properties in whatever way made sense, potentially even customizing the QtPlasmaC GUI with custom property names. That could get confusing as well though. I'm also interested in perspectives on that idea.

Thanks much!

Scott

I actually forgot to add it to the service thread, thank you very much

ok cool, if its RC servos, check out remora

github.com/scottalford75/Remora

remora-docs.readthedocs.io/en/latest/

and since im here, shameless self plug for an ultra low cost educational cnc controller

github.com/cakeslob/RRW_LAB

This may help
forum.linuxcnc.org/show-your-stuff/32029...build?start=20#85279

Ack sorry there already is a u32-bit conversion

If it does not work, its possible the you did not addf
the conversion function to the servo thread:

addf conv_u32_bit.0 servo thread

Hi I have make two linuxcnc on raspberry pi 5 both on a HAT from bot 2 byte page byte2bot.com/products/parallel-port-raspberry-pi-hat and the mill setup is working fine and the other is a lathe setup , the lathe setup is working but I dont understand why I cant get the spindle indexing work in labour ,i dont understand the behavior of that part in the Hal file and why it dont show upp in the Hal test window as working     I hope som helpfull can help me with this matter
Sinserly Krister
 

I'm trying to convert a u32 output to a bit, I managed to load it in the hal, and I managed to monitor it in the showhalconfiguration, but I didn't find much information on how the converter works, I wanted any value above 0 the bit would be 1, I imagined that was it, However, when I set a value at the converter input, the output still remains at 0. Could you give me an explanation and, if possible, a solution to my problem? thanks in advance

any updates on this?

I have the 4 axis model and pendant starts in MPG mode and i have to press either con or step button to get it moving.

also step and cont. modes seem very similar in movement in my machine.

pendant responded differently on mach3

on step mode it stepped with every pulse but i was not able to make consequtive steps as i do in linuxcnc. there was some kind of delay.

on cont. mode motion was more smooth on mach3 as if it was averaging the values. now on linuxcnc its more sensitive to the rotation of the wheel and if i dont turn it at a constant speed, it makes a stuttering motion. it it very similar to step mode.

as i said above i couldn't see the difference between 2 modes.

also i never fully understood the LEAD mode. In mach3 %100 setting meant max feedrate set at the moment for example F3000 and LEAD mode meant max possible feedrate.

I am upgrading a lathe with ANILAM control with DC servos. On that side I have no problem. The problem is with the turret for the automatic tool change. This turret is manufactured by BARUFFALDI and model TOE 100. The tool change is completely electric and the motor is 3-phase AC. It has a 4-bit absolute encoder plus a parity signal and a strobe signal. I have consulted all the components for managing lathe turrets, including the carousel, but due to the way it operates, none of them fit its operation. For what reason? All tool changes include the change of motor rotation direction, this is done by the carousel but automatically and only when the motor initially rotates forward, then if the time of the carousel pin is programmed.N.rev-pulse it will rotate in the opposite direction, but when the initial movement is in reverse it does not change direction subsequently. I understand that this function is for some type of ATC on Boxford and Emco lathes. Another problem is that the strobe pin is usually used to indicate that the position feedback signal is valid. In this turret, this encoder output does the same but in the operation of the turret it is used differently, it is not used to indicate the valid position of the selected tool, but to indicate when the strobe signal falling, but from the previous tool to the one selected, for example from T1 to T3, what is used is when the stobe signal of the tool T2 is falling and if the change is from T1 to T11, the turret rotates in the opposite direction along the smaller path , and what is used is the falling side of the strobe signal from tool T12. And what is the use given to this signal in the operation of this turret, when the drop in the strobe signal of the tool previous to the selected one is detected, this activates a solenoid that drives a cam, which initially lowers to the edge of the axis that rotates the turret and later when the axis continues rotating that cam falls into a slot inside the axis, this slot corresponds to the selector tool, which causes this cam to block a crown and in turn when completely lowered by The action of the solenoid activates a proximity sensor that changes direction of the motor rotation in the opposite direction to the initial rotation, this causes the motor to push a piece forward blocking the turret and also activates the signal from a proximity sensor indicating that The turret is locked and this in turn stops the motor and activates the magnetic brake on the turret motor.In this video you can see how the TOE 100 turret is unlocked. Initially the motor rotates an internal crown that causes the crown locking proximity sensor to be deactivated, this can be seen at the top, then it looks like The piece that locks the turret moves backwards, unlocking it and then you can see how the axis that rotates the turret begins to rotate, you initially see that the edge of the turret axis appears and then a slot appears that corresponds to the position correctness of each tool. The blockage was already explained previously.

These photos show the turret locked and unlocked as well as the soleinoid deactivated and activated.     

 


 

 

About ready to run a prototype...

 

Sounds good. Ill start poking around with a multimeter this evening.

How about this?
linuxcnc.org/docs/stable/html/gui/halui.html#_feed_override

Of course you can do this with python code too.

andypugh wrote:

All you really need to do is figure out whether the common wire is a ground or a voltage. With the multimeter in voltage mode look for a wire that stays at a constant voltage WRT ground regardless of the position of the knob.

I meant to go on to say that, once the inputs are connected to inputs in LinuxCNC we can work out the encoding then. 
 

The switches seem to be generic wafer switches, so as PCW says, you might need to figure out the wiring/encoding with a multimeter.

15 positions and 5 wires hints at binary encoding but it could be straight binary or gray-coded.

One wire will be common, and then others will be connected to that (probably through diodes) . If this is the case then you would need to set your multimeter to diode-check mode as the ususal voltage used to measure continuity is too low to overcome the forward voltage drop in diodes.

All you really need to do is figure out whether the common wire is a ground or a voltage. With the multimeter in voltage mode look for a wire that stays at a constant voltage WRT ground regardless of the position of the knob.

meister wrote:

Hi means an output for RC-Servos

Yes, exactly, a three wire RC servo to control the gripper.  I overlooked how to control this pseudo axis.