Advanced Search

Just an idea.
The last position that will be recorded will be the last data that that was successfully written to the hardware from the file buffer.
Now the power going out will be for all intents and purposes a random event, there is no guarantee that any particular data will be successfully written to hardware before a power outage.
The only way I can see everything happening gracefully is with a UPS, that once detects a mains outage is able to shutdown gracefully. But the machine itself may not be in the exact position you expect due to inertia and any other unknown factors mechanical or electrical.
So basically data not being written the disk is more of a limitation of an OS when power is removed suddenly.
Also one would hope the file being written to is not stored in tmpfs (ram) then written to disc during the shutdown process of Linuxcnc.

Haha, that brings back memories 

There are two products here in the picture
 
www.aliexpress.com/item/1005001579853052.html STM32F407VET6 dev board
www.aliexpress.com/item/1005007182508975.html LAN9252 slave dev board

The STM32's pins on the LAN93252 dev board are limited to those in the pin header, which wasn't enough.
For test it can work if the needed pins are available in the header.
One can use the LAN9252 of the kit, which is what I did and hooked it up to the STM32 dev board
where I had access to all pins.SPI+sync0,syc1,irq lines.

I now see in some searches there are other LAN9252+STM32 development boards which are better suited, maybe this one?
 
It can pay off to do a search. You want access to the Timer's encoder inputs, which 
are different for different models so it's a puzzle.

Schema for STM32F407ZGT6 on the LAN9252 dev board
 

The remap is done with a simple .ngc routine, for adjustable toolchange/probing position, from a spinbox value. change.ngc completes without error., then it crashes. So the problem must be with  epilog=change_epilog.  I did not modify   stdglue.py  . The manual tool change option from .hal file is working


[RS274NGC]
REMAP=M6  modalgroup=6 prolog=change_prolog ngc=change epilog=change_epilog


 

I think you might be misunderstanding what LinuxCNC does. If the machine responds to low-level commands through the serial port then I think that the CNC controller is on the machine side of the serial port. LinuxCNC is a CNC controller, so that is where half of LinuxCNC would go too.

Hi, I have an issue in Gmoccapy.When I try to click on “Clear Toolpath” or “Jog Speed –”, the cursor automatically grabs the edge of the preview window. Instead of clicking the button, it starts resizing the preview window.It feels like the preview window border has priority over the buttons, so I can’t reliably click them. Has anyone experienced this, or knows how to fix it? 

@Hakan certainly a stupid question but I did not understood why you did not managed to get the encoder work on the ethercat devboard here?



I wanted to test the encoder on the devboard before doing a custom board
Thank you for the clarification

I have my MAX-Z-LIMIT set at 20mm & MIN-Z-LIMIT set at -255

Usually when I run a program, as I set home and stuff like that manually I'd home to a mark on the column, then bring the tool down to a height of 6.35mm above the stock, set by a pin, touch off at that height. Which sets the Z zero on the stock.

Unfortunately the 2.9.3 image you refer to has been removed from the server.
There is a new image that has 2.9.7 and is much more raspios like.
The thread is here which has one image suitable for both the 4 & 5:
forum.linuxcnc.org/9-installing-linuxcnc...trixie-images#338181

As this is an experimental image I would be very interested in feed back.
If you need to install probe basic there are 2 extra packages to install after following the Probe Basic install instructions:
forum.linuxcnc.org/38-general-linuxcnc-q...-launch-issue#338654

If you are not installing Probe Basic there is no need for these packages.

Hi, this is my first post outside of the Ethercat section.

I'm getting beat up by a z axis travel limitation, although I did somehow get the program to run once. My understanding of the problem is that my g54 is in the wrong spot. 

Fusion 360 says the max Z height is 0.6", so I moved my Z axis almost all the way up, then set the G54 Z position to 0.6". I did have the program run once, but then I stopped the program. When I go to re run the program I keep getting the same z axis error.

I've attached some phone pictures.

   

And one more question. Can I use the same encoder for both feed and MaxVel? I don't really like the two-button operation for feed control

My maxveloverride isn't working. It's on enc3, and spindle override and feedrate override work there, but not maxveloverride. Is this due to gmoccapy? The entries in the HAL file look the same as for spindle and feedrate.

Ok 500 is fine. I knew it is 1000 for 1 ms but not how it scaled.
I was looking for a reason for the following error.
Since the feedback comes from the step generator and not the actual machine,
it seems to me the step generator is to blame.
You get following error even when running in air, right?
Basically linuxcnc, or perhaps the step generator, generates the wrong tool path in Y.
Unfottunately I don't know how to fix it.
 

This image was previously available, but when I tried to reinstall it, I couldn't find the specific "

Interesting I will give it a shot repairing the hydraulic system before abandoning it.

forum.linuxcnc.org/18-computer/54314-10-...ble-retrofit?start=0