Advanced Search

Hey Tommy!

Thank you!

I will be using a Hypertherm 85xp so the cut width capacity is around 3/4”… sort of. The angled cut thickness will have to be tested and tried. I’ll see if there are alternative tips for angled cutting and pressure recommendations. Good point!

any thoughts on programming the machine to know the offset? Say I angle it 45 degrees, when it plunged down it will have to plunge further than it normally expected to detect the material. Then once it is ready to start cutting the torch top will be whatever distance offset from the machines predicted cutting point, since it’s set to one side at an angle. Can I set specific offsets for the machine, then assign those offsets names like “15 degrees angle”? 

I would recommend using either one of these prebuild images for pi5:

[1] Without network manager UI
drive.google.com/file/d/14rVniZWJ7DqbIxQ.../view?usp=drive_link

or

[2] With network manger UI
drive.google.com/file/d/11XX6SdbaO0tL1Zg.../view?usp=drive_link

 

Bangs head against the wall.
So simple. 10.10.10.10 is not the default but the EEPROM default. Select the EEPROM.
So now I just need to figure out how to set up the eth0 port on boot and I can start to load Linux CNC.

Thanks for putting up with a dumb ol' 74 year old.
If I get any more stupid I'll have to become a politician.

meister wrote:

On the Tangbob board I use the TXS0108EPW with pull up/down resistors on the input side.

However, to switch optocouplers in the output stages, for example, you still need a driver like the ones installed on the BOB boards (uln2308), the level shifters are not designed for this

Yes, the output of the TX0108E is not directly driving the optocoupler.  There is a simple parallel port Break out board in between. This allows me to switch back to my current linuxCNC parallel port PC and I was able to confirm that the problem is not anywhere behind.

I tried the pullup/pulldown resistor also on the input side, no difference. Forgot to mention that. Anyway, if I don't have the new level shifter by the end of the week, I will see if I can invest some more time in the TX0108 otherwise I just move on to the new level shifter. They were a $1.50 each, not worth spending hours to get them working.

@Akb1212,

No worries. For wire edm you could set unlimited program history.

Maybe related to the bug I mentioned with update rate:

   If you ever set the update rate to 0 (maximum), changing to a
    non-zero rate will not work (communication stops)

 

@Robh,

superimposed control.

Rob, you inspired me. It's really fun to get this running.
Now i let it run for a few hours. Everything goes well. Mutexes are set correclty.

Here it runs a example of 3 interpreters :
- Master interpreter xyz
- Sub interpreter abc
- Sub interpreter uvw

The master interpreter is sending programs to the sub's.
There can be set a flag that master should wait for sub to complete.
Without the flag set in the gcode, the sub will just run without callback.

 

Altough i have still a question.
At wich point path optimisation is the best to do?
Is this outside the while loops? Outside every command like WHILE, GOTO, IF, etc.
What do you think about it?

Specs super imposed interpreter library :
Load multiple (sub)interpreter in a pool.
Every interpreter run's in it's own thread pool. (multi threading)
Variables, conditions, expressions are solved by the mu::parser library.
Support for nested while loops, if goto, and a few others. Not complete yet.
Adjustable buffer, cq queue size.
Machine callback function. Machine sends ok to recieve next gcode line.



source codeberg
 

Hi please can send pics for understand geometry de machine ?

I am not getting to the stage of installing. Once i have done the add the url and pgp keys then the next step of doing sudo apt-get update is when the error happens.

It gives the list of the known sources with the error at the end and the source for probebasic is listed but errors out.
[/code]

meister wrote:

digiex_chris post=313820 userid=40887
well, last night I got first movements to work on my iceshield derivative, and got the scale correct. Trying to get my head around the PID settings, I'm a bit lost since I'm normally a stepper guy working with more direct controllers that work similar to parallel port setups, 1 step = 1 step moved, no hunting position. this seems to be treating the fpga as it would treat a servo with encoder feedback. The position doesn't quite reach the commanded position, and it hunts a little, which I find odd for open-loop steppers with no encoder feedback.

Can anyone enlighten me on how to tune this? Is P too high? I have a feeling it maybe should be set to 1.0 instead of the default 250 so there is no gain.
 
the pid-loop is necessary with external hardware, as only velocity information can be sent in this way.

The deviations are actually only rounding errors, which should be no different with mesa hardware.

Remora does it the same way, only with a little trick, there the PID controller is hidden in the driver and linuxcnc does not show the calculated values but those that were sent.

In the beginning I also had the PID controller in the driver (linuxcnc-component), because it was only a copy of the remora driver, but that is actually just optics.

so far, the position has always been accurate to the step...

tuning is also not necessary if you use stepper

Thanks for the explanation. In that case, with the default config, I don't understand why, if I adjust scale, I end up with the position reported to LinuxCNC being unstable. The value in the DRO flickers. The error shown to LinuxCNC is also much larger than I can tolerate, as much as 0.04mm, fickering as much as 0.1mm in either direction. even if the mechanical side may or may not be that accurate, since there is no feedback like an encoder, it should be a stable reported position. The position shown in LinuxCNC never quite equals the commanded position within 3 decimal places, so some of my automation that detects if the table traverse is equal to or greater to the commanded position rounded to even 2 decimal places (in metric) doesn't work. 

Thinking about it more with your comment, I think maybe the machine is moving the correct amount, but the position reported back to LinuxCNC isn't correct or isn't stable, for some reason. How can I look into this further? If it were just floating point rounding error, once the iceshield had arrived at the correct position, shouldn't the reported position then be stable at the rounded value, instead of flicker? My X axis is very coarse, so I am comfortable with it not having high precision, but the flickering reported value (shown in the DRO) is very odd given that it's a stepper.

Do I need to re-flash with each change of scale, or is modifying it in the .ini sufficient?

For reference, 
config: github.com/digiexchris/6x11-sg-grinder-l...reconfig/config.json
generated ini: github.com/digiexchris/6x11-sg-grinder-l...eld/LinuxCNC/rio.ini

but I have changed the scale to 11.64 (yes, very coarse) for the X axis but that's what was required to get 10mm of movement from G1 X10 with a surface grinder table driven off of the normal handwheel (it's quite a large movement per handwheel turn)


I think I'll change the microstepping up to 32k so I can get the scale number higher and see what effect that has on the stability of the reported position.

Well, I found something already. There is a divide-by-zero on line 525 below (line numbers differ slightly from official code), because inst->hal->rate is not initialized in the code, and at least in my case it defaults to zero. Changing it to 1 from halshow causes the jumps in position-fb to stop. At least for now
 

I guess the divide by zero causes a fault/interrupt handler to be called and the execution state/context may be lost/upset? At least I'm imagining something like that. If somebody can produce a better or more accurate explanation, it would be interesting to hear.

This seems to me like a clear bug. Is somebody able to take this forward from here, or give me advice on how I can make a bug report?

edit: The hal pin related to inst->hal->rate is named update-hz. I though I'd point that out, as the connection is by no means apparent from the screenshot.

down/down on IP address jumpers is 192.168.1.121
down/up is 10.10.10.10 

(W15 down, W16 up on a 7I95T)

(after a power cycle)

Right. I did a new rebuild on a later kernel from the thread LinuxCNC 2.9.2 and 2.93 images for Raspberry Pi 4b & 5
Nobody seemed to be screaming that it destroyed civilisation so I put it on an SD, booted it and flipped it onto the NVMe.

This is with a six inch cat8 cable between the Pi5 and the Mesa.
This is silly. I must be having a senior moment here. The board is definitely jumpered DN DN and the
documentation assures me that that means 10.10.10.10 on 'as delivered' firmware.

cnc@Pi-CNC:~$ ping 10.10.10.10
PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
From 10.10.10.11 icmp_seq=1 Destination Host Unreachable
From 10.10.10.11 icmp_seq=2 Destination Host Unreachable
From 10.10.10.11 icmp_seq=5 Destination Host Unreachable
^C
--- 10.10.10.10 ping statistics ---
7 packets transmitted, 0 received, +3 errors, 100% packet loss, time 6150ms
pipe 4
cnc@Pi-CNC:~$ sudo ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.10.11  netmask 255.0.0.0  broadcast 0.0.0.0
        ether d8:3a:dd:b0:cf:14  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 89  bytes 14327 (13.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 112  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
 

For information, and in case it gives somebody any ideas. I started looking at the mesa_modbus.c.tmpl code, and modified it to output its internal state as a HAL pin. Attached a screenshot from halscope where the state is visible alongside the jump in position-fb.
 

The states are defined by:
So, we start in state WAIT_FOR_DATA_FRAME, then go to RESET_WAIT for a few cycles, and the in either state START or WAIT_FOR_SEND_BEGIN, the jump in position-fb occurs.

tommylight wrote:

Transistors should work, probably better low side, but do add a resistor between the Tang output and transistor base, something like 470 Ohm or 1K should be OK for normal signaling transistors.
Also, normal transistors do not require resistors between base and emitter for normal switching, MOSFET's do.
 

They normally don't, being current controlled devices, but I have seen instances of ghost activation in noisy environments (transistors do have a Miller capacitance, it's just much smaller electronics.stackexchange.com/a/95984). For prototyping I don't usually bother but if I'm ordering up a board I will add them since they're basically free.

Yes I forgot the base resistor!!!