Advanced Search

Bump to remove it from "no replies" list.

Did all this and some more 2 days ago while i was building a small 4 axis cnc machine and waiting for it's parts to print (not shown here, but the round teethed thing shown here is also for that machine).
Notice the changes on the FreeCAD GUI, made it much more enjoyable to use

Yeah, no idea how to put this nicely, but you can not just put values at random and expect things to work, so:
-linear joints/axis must move in positive space, not negative
-z axis must move in negative space
-rotating axis/joints can move either way, depends on what the CAM being used outputs.
The above "must" is conditional as there are situations when stuff needs to move in negative space, but those were usually very old cnc controls.
First figure out what your CAM outputs, then set the workspace accordingly.
Then make sure the axis/ joints move in the correct direction, spindle going from left to right side should be increasing positive values for X on the DRO, spindle moving away from you should also increase values for Y in DRO, and spindle going down should increase the negative value for Z in DRO.

An interesting discussion, I've used FreeCad for a while for 3D printing.  Most of the machining I do is too simple to demand intervention by CAD so far

If people want information on some interesting concepts in FreeCad, here are some YouTube channels that might interest:

www.youtube.com/@4axisprinting/videos

https://www.youtube.com/@MangoJellySolutions/videos

www.youtube.com/@CADCAMLessons/videos

There are others, but I don't want to make this too lengthy

Glad you figured it out.
Now add some HOME_OFFSET to all joints so they back off of the switches when they finish homing sequence, usually 2-3mm are enough. And also set the HOME_FINAL_VELOCITY to something reasonable as by default they run at full machine speed for those 2-3mm, on fast machines that is terrifying!
Keep the HOME_ velocities low till you get all joints homing properly, joints move toward the switch, then back off, then again towards the switch and finally those 2-3mm and stop.

How does LinuxCNC/Mesa know there was a fault?
If drives have fault out, there might be something we can do, but for now i am out of commission as i spent the whole day chasing python scripts to output gcode for 3 and 4 axis machines from some really obtuse files some proprietary software outputs.

I think my original reply did not save - these did not work unfortunately

I remade from scratch a pncconf with axis gui. again in pncconf I am seeing the GPIO-000 pin and input-00 correctly change state when i press the limit switch. Similarly I see on the board the LED light of input-00 change state

However, when I run the actual axis instance, and use hal meter to view gpio.000 or input-00 neither change state anymore, HOWEVER, the led light on the board continues to change states correctly.

I am at an utter loss. It almost seems like the input side of mesa is not communicating when I am running the software, but I do not understand how that is possible. Do you have any other thoughts? I am at a complete loss

EDIT: I have an important clue I discovered: If I open my first machine's instance of linuxcnc, and go into hal config, then I am able to see my limit switch activate successfully. I believe this means there is some issue with having two of my mesa's on this computer even though I only have one plugged in at a time. Has anyone encountered this and know of a fix? I will purchase a new computer most likely regardless but I am still hoping to figure this out while I wait.

EDIT2: I am trying to change the ip address of this second mesa to 10.10.10.11 ( I have w4 and w5 set to eeprom). It says it changed successfully, but when I try to readhmid it says no board found, and I can no longer communicate with the board. So trying to fix this now... (when I do ping 10.10.10.11 it does ping successfully)

Edit3: I have successfully changed the IP address to 10.10.10.11 and connected it back to my computer and it STILL only works in pncconf but NOT when i run my linuxcnc!!!!!

What informs the GUI as to where the virtual spindle is placed in reference to the bounding box? (What else, other than using the center of the min and max joint values for each joint)

 

Less verbose question that would help the situation:
What informs the GUI as to where the virtual spindle is placed in reference to the bounding box? (What else, other than the center of the min and max joint values)

Summarized Problem: Why doesn't the orientation of the spindle in the AXIS GUI reflect the actual position of the machine's spindle in space? Within the bounding box. The bounding box dimensions and size are correct. 
 
In our Linux CNC configuration when we turn on the machine and open AXIS, the GUI displays a 3D bounding box built by the min and max values given for the joints/axis in the INI file.  The GUI then puts the virtual spindle in the center of our workspace which is fine initially however our HOME position for our Bostomatic 3-axis milling machine is in the top front corner. I was expecting that when we press home all then the GUI virtual spindle will realize it is not in the correct position, however it does not, after it homes the virtual spindle is in the same position in AXIS  as when the application opened (the center). Where as our machine correctly went through the homing procedure where the soft-limit switch and home is shared and the actual spindle is now in that top front corner (which would be the top front corner of the GUI bounding box if it did what I wanted it to).  In this config the min and max values for the x, y and z axis are respectively (-9,9), (-6, 6) and (-6, 6). Which makes sense why AXIS is assuming that the origin, (the (0,0,0)) is the same at the home position.  So then I thought the solution would be to change the x, y, and z axes' mins and maxes to be: (-18, 0), (-12, 0) and (-12, 0) so that the (0, 0, 0) position is that corner where the home actually is.  This does put the virtual spindle in the right position. However this messes up the range of the axes because is assumes the position the machine is in when it is turned on IS on the edge of the bounding box and therefor won't jog in the positive direction because AXIS thinks it has no room but the machine indeed does. And therefor the GUI and the machine are still not on the same page just off in a different way.  We have discovered using G92 to help align the g code but this does not solve our problem.  SO, how do I get AXIS on the same page as the machine.

 

Thank you but i have seemingly stumbled upon an issue with estop i cannot resolve in any way. Even without any further hal functionality, just ini, configuring a basic gmoccapy and a base hal doing nothing but estop logic i can´t reset estop.

Current version i am trying. I can set external estop via halcmd to either states and try to reset estop with F1 GUI estop
I have built pretty elaborate estop logics with debouncing of external estop time delays and everything, but can´t get emc-task 3 (OFF but no estop) to show.

 

I think i might have figured it out.

because the homing seek rate was super slow (so i didn't break anything) it was difficult to tell, but one of the motors was actually moving in the opposite direction, giving it the appearance that only one motor was moving. (i've already ordered replacement motors, as it seems one was stronger than the other)

i had to manually change the hal file
'''
setp parpart.0.pin-09-out-invert 0
'''

After that, they both were moving at the same speed and rate, in the same direction.

Final Note:

Thank you guys for the help, and sorry about the opening rant. the frustration was VERY real for me.

Aciera wrote:

Looking for 'WRAPPED_ROTARY' in the source code seems to suggest that it indeed only applies to axes A,B,C:

~/git/linuxcnc-dev$ grep -rnw ./ -e WRAPPED_ROTARY
./configs/sim/axis/wrapped_rotary/wrapped_rotary.ini:85:WRAPPED_ROTARY = 1
./bin/axis:3516:a_axis_wrapped = inifile.find("AXIS_A", "WRAPPED_ROTARY")
./bin/axis:3517:b_axis_wrapped = inifile.find("AXIS_B", "WRAPPED_ROTARY")
./bin/axis:3518:c_axis_wrapped = inifile.find("AXIS_C", "WRAPPED_ROTARY")
./src/emc/rs274ngc/rs274ngc_pre.cc:872: inifile.Find(&_setup.a_axis_wrapped, "WRAPPED_ROTARY", "AXIS_A");
./src/emc/rs274ngc/rs274ngc_pre.cc:873: inifile.Find(&_setup.b_axis_wrapped, "WRAPPED_ROTARY", "AXIS_B");
./src/emc/rs274ngc/rs274ngc_pre.cc:874: inifile.Find(&_setup.c_axis_wrapped, "WRAPPED_ROTARY", "AXIS_C");
./src/emc/usr_intf/axis/scripts/axis.py:3514:a_axis_wrapped = inifile.find("AXIS_A", "WRAPPED_ROTARY")
./src/emc/usr_intf/axis/scripts/axis.py:3515:b_axis_wrapped = inifile.find("AXIS_B", "WRAPPED_ROTARY")
./src/emc/usr_intf/axis/scripts/axis.py:3516:c_axis_wrapped = inifile.find("AXIS_C", "WRAPPED_ROTARY")
./src/emc/usr_intf/gremlin/qt5_graphics.py:274: self.a_axis_wrapped = self.inifile.find("AXIS_A", "WRAPPED_ROTARY")
./src/emc/usr_intf/gremlin/qt5_graphics.py:275: self.b_axis_wrapped = self.inifile.find("AXIS_B", "WRAPPED_ROTARY")
./src/emc/usr_intf/gremlin/qt5_graphics.py:276: self.c_axis_wrapped = self.inifile.find("AXIS_C", "WRAPPED_ROTARY")
./src/emc/usr_intf/gremlin/gremlin.py:204: self.a_axis_wrapped = inifile.find("AXIS_A", "WRAPPED_ROTARY")
./src/emc/usr_intf/gremlin/gremlin.py:205: self.b_axis_wrapped = inifile.find("AXIS_B", "WRAPPED_ROTARY")
./src/emc/usr_intf/gremlin/gremlin.py:206: self.c_axis_wrapped = inifile.find("AXIS_C", "WRAPPED_ROTARY")
grep: ./src/objects/emc/rs274ngc/rs274ngc_pre.o: binary file matches
./docs/src/config/ini-config.adoc:902:* `WRAPPED_ROTARY = 1` - When this is set to 1 for an ANGULAR axis the axis will move 0-359.999 degrees.
grep: ./lib/librs274.so.0: binary file matches
./lib/python/qt5_graphics.py:274: self.a_axis_wrapped = self.inifile.find("AXIS_A", "WRAPPED_ROTARY")
./lib/python/qt5_graphics.py:275: self.b_axis_wrapped = self.inifile.find("AXIS_B", "WRAPPED_ROTARY")
./lib/python/qt5_graphics.py:276: self.c_axis_wrapped = self.inifile.find("AXIS_C", "WRAPPED_ROTARY")
./lib/python/gremlin.py:204: self.a_axis_wrapped = inifile.find("AXIS_A", "WRAPPED_ROTARY")
./lib/python/gremlin.py:205: self.b_axis_wrapped = inifile.find("AXIS_B", "WRAPPED_ROTARY")
./lib/python/gremlin.py:206: self.c_axis_wrapped = inifile.find("AXIS_C", "WRAPPED_ROTARY")
 

Thanks so much for checking.  I'll try to figure out a different solution.

I am running a 3 axis CNC mill with stepper motors, through a 7i76eu card running linux CNC. Currently when one of the motor drivers gets a fault, the motor lose all power. This is problematic for the Z axis, which uses a stepper motor with a brake. When its driver gets a fault the brake is engaged, but there is a delay, in the meantime the z axis is in free fall for about 10cm. Is it possible to program the stepper drivers in such a way that when they get a fault they stop the motors and hold the position.

Thank you for all the answer and suggestions in advance.

Yes it is, but that also depends on a lot of other external conditions, like current set, air supply and pressure and moisture in it, nozzle size and type, feed rate, material composition, etc etc, so any of change and the cutting result will change, most of the time not noticeably but sometimes very noticeably.
If you have an older plasma source with a big transformer, that will also vary with the input voltage and spikes and drops in the line ripple.
As a general rule:
-thinner material or faster feed rate = more P
-thicker material or slower feed rate = less P
-
On most of my machines i have it set at 7 and never change as they do mostly cut the same 2-3mm material all day long but sometimes they do cut 6-10mm thick so it works fine for both materials as the wavy cut is not very noticeable on thin material.

Solved 

config below