Advanced Search

Are you dropping packets? that is, what is:

hm2_7i76e.0.packet-error-total

A dropped packet will result in a (bogus) following error spike,
as stale stepgen position (from the previous cycle) will be compared
with the commanded position. At a 2 ms servo thread period and 125 mm/sec
velocity, a .25 mm reported following error value is possible from a dropped
packet. Note the this does not mean that there is an actual path deviation
of this magnitude, this is bounded by the max_error PID pin to ~.0127 mm
per dropped packet.

I still think the physical error is most likely mechanical as it only shows up on Y.

To diagnose stepgen errors, the best thing is to plot the following error
with halscope like this:

 


Note that this is in inches, but the velocity and acceleration are about 4x and 6X your machines values
and the inherent stepgen error is less than  0.25 micron.

Another possibility if the system latency is really bad, is loss of DPLL sync, so you might try increasing
the DPLL time from -250 to -500 usec

 

Hola! Tambien soy Argentino. He comprado directamente a Mesanet sin problemas en varias opurtunidades y te lo envian ellos mismos por correo. Tambien puedes probar en esta pagina:
eusurplus.com/index.php?route=common/home

Si no me equivoco son de Portugal y en ocaciones puedes encontrar lo que no consigues en mesanet.

Saludos!!

are getting reported when from driver's or linuxcnc? What is the axis drive type? Bal screws or rack or belt? Edit: Nevermind saw c5 screws 

Your fixed bearing arrangement isn't ideal. Ac bearings should be matched sets requiring no intermediary spacers for preload.  Adjusting correct preload with spacers between the bearing set is incredibly variable and difficult.  It is for certain an easy way to destroy bearings as I've done it in the past and turned the balls to crumbled bits.  That said I don't think that's enough for your deviation, just a suggestion for future improvement. 

Feed forward is used with PID tuning for servos and a feed back loop, if your using simple steppers this shouldn't need an adjustment over the ff = 1

 

I made a spelling mistake when i entered it into the INI file. It's working now.
Thank you

Mesaflash shows physical pins, and which firmware modules are included
in the current installed firmware. What you need for hal file creation/editing
are hal pins and parameters.

To show all 7I95T hal pins and parameters:

1. Start LinuxCNC

2. In a terminal window type:

halcmd show all hm2

if you want a file containing these pins and parameters (for use as a copy/paste donor file):

halcmd show all hm2 > 7i95pins.txt

For documentation on the modules and their pins and parameters:

man hostmot2

This is a mod that allows using a single key ("c") to cycle through all jog modes and increments.

From continuous to every increment in order, back to continuous.

Ok got the card running so far, controling a stepper motor is working.
After reading the card via mesaflash well missing a lot of pins
Only have like 57 and there compleatly wrong, was to be expected, it should have in total somewhere around 144 pins.

Unfortunatly i am unable to research what bitfile to load do to lack of documentation from mesa.
Ether im blind ore there is nothing in the docs.(see attachment)

Thanks for helping

Trying to launch Qtdragon that was working before a failed probe basic install is giving the following error report. Any help would be greatly appreciated!!!

Thanks, Hakan. Yes, yesterday I cancelled my Air-path as I could see the motor is going into alarm. I don't know if there is a following error as a reason for this, Iwill pot my serial connection to the motor today to read the logs and reproduce the error.

What I can say, mechanics are not the reason, because - what I changed just before were the entries at FERROR and MIN.FERROR to 0.1 and 0.01, exactly what is in the x-axis, which is running fine with these settings.

I can't test without the files you are using or a sim config containing all the files you're using.

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?