Advanced Search

Thanks for the explanation, it really helped. I made indicators for e-stop, on/off, manual mode, and MDI. There was a slight issue with auto mode. I wanted to make indicators for auto mode, running programs, and pause. This is the only way I could do it:
Is this ok, or is there a more elegant way?

I don't think modern drives loose torque with microstepping. I ran 25x microstepping on my machines.....But yes I was considering how much microstepping I could use. Maybe 8x. Adding a belt reduction is often the wise choice.

Yes, I found the specs in the manual. Seems like you could increase velocities

Sekai wrote:

i tried with the ethtool but no change
 

after reading some more i disable AMT setting from bios but the value remain the same

Please fix the coalscing setting and report back also energy efficient Ethernet could impact from time to time if enabled.. 

Sorry, I based he code on my experience but now I see your situation is different. You could modify the code to achieve what you desire. Just swap things around.

I made fresh install from 2.9.4 ISO then update & upgrade to 2.9.7 and you can add new mdi command only after the previous one has been executed
I though this bug was already fixed, can anyone tell me is this only problem with my config 
thanks
 

abs32 wrote:

it seems to me that this is "not sporty". Together we must force the correctly given commands to be executed correctly. G38.3 should not produce such errors.
You suggested changing the interface to qtplasmac, but it uses the same g-code and linuxCNC. And I have a milling machine.

The difference is that  qtplasmac does not use gcode to control the torch height and it does not use Gcode to probe for the surface. Any gcode affecting the Z axis are ignored as they are filtered out when the file is opened.\. As I said that is al done with external offsets. That is, external to the motion controller. Please watch my video overview wnad read the comprehensive explanation in the comments. 

Hello,
your problem is not the amdgpu.
That is the "normal" raspi-firmware-bug. Please use: sudo dpkg -P raspi-firmware
I think the amdgpu error message you can ignore. I have the same on my old amd-test-pc

Beovoxo wrote:

Hi all, i tested again today with a fresh download of  2.9.4 from the main page. And now i am stuck as all the other ones are at, the missing "amdpgu fault". 
Was there a solution on that fault ?, i cant decipher if there was one, on all the other forum posts with that fault. 
ibb.co/G4FrwL3t

If there is not a solution i will try the "mint" Tommylight uploaded 

 

emresensoy wrote:

Now we are among the hardware providers.
www.egerobotics.com

Do you have a driver in the LinuxCNC distribution? (Do you want one?)

 

Please correct me if I'm wrong.
Dealing with a previous mistake
forum.linuxcnc.org/38-general-linuxcnc-q...ue-with-g38-5#337899
it was completed with a victory via a patch -
github.com/LinuxCNC/linuxcnc/pull/3537/c...54ead378bbe05398b9d2

This patch changes the src/emc/motion/control.c file
I prefer the idea of using versions with a real-time kernel, which obliges me to use version 2.9.4. The version of this file in the source code 2.9.4 and 2.9.7 differs in the inserts for this patch. Therefore, I bring this file for version 2.9.4. to the state version 2.9.7 = error correction "probe tripped during non probe move"
Then to implement the version of the respected comrade. AkkiSan from forum.linuxcnc.org/38-general-linuxcnc-q...bing?start=10#333578
changes should be made to the src/emc/rs274ngc/rs274ngc_pre.cc file (this file is the same in versions 2.9.4 and 2.9.7 before the fix).
Then you need to build and run.
The trouble is that I have an ArchLinux fast car, but a combat car with a machine tool is leisurely. I'll try to collect it.

Did you also get the M19 and axis-to-spindle switch to work as you said there were some issues?
My first thought there was to just verify the drive is actually switching modes, you have the 
opmode-display from lcec you can watch.

Published error traversal methods based on wrapping a signal through a digital input cause g38.5 to fail and be replaced by G0 or G1 - an erroneous path due to poor accuracy and surface finish speed. I experimented and compared the smoothness of the result with G38.5 versus G0\G1. To use G0\G1 for rebound, you need to set an excessively large amount of upward rebound, which radically reduces the speed of surface treatment and just as significantly increases the noise of the operation.
Conclusion: we must fight to correct the error.

Good morning everyone.
Rodw, yes, indeed, the pin for freewheeling will be managed by a GUI.
The idea is good, but in practice, we wouldn't solve anything, because when the operator selects mechanical movement and the pin switch is executed, we disable the drive.
In this case, for example, pos.command is 200 mm.
Now the operator can move the axis mechanically.
Let's imagine that it has reached -1000 mm in the feedback position.
Now the operator disables the mechanical handwheel, we execute the switch, and re-enable the axis, but LinuxCNC will issue a ferror alarm because the commanded position is 200 mm and the feedback is -1000.
Clearly, increasing the ferror parameter to 1000 mm is not feasible.
In reality, the only way to adjust the command position value to the feedback is to turn off the auxiliaries so that LinuxCNC copies the feedback position to the command position, and then turn the machine back on.
This axis parking feature is useful in many situations, even on mechanically indexed axis tables.
We need to find a way to modify the LinuxCNC code so that it switches a pin and the command position follows the feedback, just like when LinuxCNC is disabled with an emergency.
In this case, if you rotate the encoder or move the scale, the command position follows the feedback.
There should be a pin for each axis, which can be enabled on the fly.

i tried with the ethtool but no change
 
after reading some more i disable AMT setting from bios but the value remain the same

I have a cnc machine with a carousel atc (24 pockets, 10bit encoder), using gray scale absolute encoder and my intention is to use the carousel module to control it.

In initial tests with the module got me getting questions so I have looked into the code at since i did not understand the position value:
github.com/LinuxCNC/linuxcnc/blob/master...onents/carousel.comp

The value I am getting is the raw value as current-position from the carousel component, this is not wrong but I got curious so I looked into the code and now I got more questions regarding when calculating the target position.
In all places in the state machine where the target position is calculated the current_position is used without scaled to the same "size" as the target pocket.
I do not know if I have understood the code correctly or missed something. Maybe I would need to update the component to my specific case.
I think I in my case needs to scale the wanted pocket value to bit value to calculate how far the ATC needs to travel.

Have i understood this correctly or am I missing anything?