Advanced Search

I have a SainSmart 5 Axis Breakout Board for Stepper Motor Driver CNC Mill board.  I want to drive a hot wire relay with it.  It has NO, COM, NC connectors - how do I wire these to the relay, and how is Linuxcnc configured for this? I connected the inputs to ground and NO, but an M3 does not trigger the relay

Dies ist zwar die richtige Vorgehensweise, der Inhalt der von Ihnen geposteten Datei entspricht jedoch nicht dem, was in einer Konfigurationssicherung erwartet wird.

I have experimented with 60m/min and 0.8 G Accelleration (8 m/sec/sec) on a plasma table and can confirm what Don says that the inertia at this level of performance will shake your machine apart. People seem to gloss over that part of his discussion but it is very true.

Hence the need for jolt limited tool paths.
Which shows, for high performance CNC machining, one needs to fine tune every component of the system. Toolpath, software, electronics, mechanics and ambient atmospheric conditions. The effort required climbs exponentially.     

Hello,

sorry for asking without being able to give any valuable details. I have no logs, and the issue I had is not reproducible. But it was quite disturbing, so I'll try my luck and ask if this maybe rings a bell to someone out there.

I have installed LinuxCNC 2.9.2 on a Raspberry Pi 4, the image from the LinuxCNC page. Before I had 2.8 installed, which flawlessly cut many chips.

I'm running (as before) Gmoccypy.

After installing, I took over my config files from 2.8 and was surprised that it actually worked quite nicely out of the box. I installed ProbeScreen for LinuxCNC 2.9 (github.com/verser-git/probe_screen_v2.9); before I already had installed ProbeScreen for LinuxCNC 2.8).

Already cut some chips including tool length sensing etc, everything just flawless.

But today something VERY strange and disturbing happened: LinuxCNC had been running for some days, machine was homed, so I just loaded a GCode file (but did not start it yet) and then wanted to first touch off the tool probe with my 3d probe (which I always do and had done several times already with the new set up).
It drove above the tool probe, approached, touched, retracted, touched slowly, retracted - and then started the spindle motor!! Of course the probe cable was ripped apart and I was left shocked.

Then I tried several times again (with the 3d probe not attached and simulating touch-off by hand). It did the very same each time. Then I restarted LinuxCNC - and now it behaves as usual again.

Normally, when such things happen, I just frown a bit and am glad that the issue resolved. But here I am really curios how this could actually happen.

What I've seen is that I have repeated errors on the MB2HAL, I think every 2nd transaction does not work. But even with these error, the spindle works flawlessly (I will take care on these of course). My first guess was indeed that there was some glitch on the modbus, causing the spindle to start, but as it started after each probing repeatedly I don't think this is the issue.

I think, if I don't explicitly collect logging data from stdout, I don't have any logs, right? I should have stored the stdout (I even had LinuxCNC running from command line!)

Any idea anyone how this could possibly happen? Again, sorry for the sparse information, I know it's hard to tell anything without seeing any logs.

BR Simon

Ich habe auf Backup config in qtplasmac rechts unten geklickt und diese angehängt. Oder welches Backup soll ich benutzen oder ich habe die falsche zip erwischt sry.

Here is a post regarding vector format that actually seems to be familiar with it.
forum.linuxcnc.org/10-advanced-configura...gcode?start=0#143455

As for the absence of arc moves in vector format code see this post in the same thread:
forum.linuxcnc.org/10-advanced-configura...gcode?start=0#143507

They use I,J,K for vector. But for G2, G3 that is not a valid gcode input.

Yes, that is because the 5axis CAM output only consists of straight line segments (ie no G02 or G03 commands) the CAM user defines the length of the line segments.

I'm not suggesting to limit the interpreter to this format but it would make a lot of sense to allow vector format as an option since it makes the calculation of the tool vector unnecessary. It seems kind of silly to have the CAM calculate the tool vector and then to invest in a postprocessor to calculate the rotary angles from the tool vector just to have your algorithm reconstruct the tool vector that we already had in the CAM output.
So basically:
1. Check if the first G01 command has I,J,K words
2a. if no then read the machine kinematics from the ini file and recalculate the tool vector from the ABC values
2b. if yes, use the IJK values to create the tool vector directly.

 Basicly when using external rotary table, we could use this as axis u,v,w.
Where u=rotation around x, v=rotation around y, and w=rotary table clamp symetric axis.

Then we have a xyz, abc, uvw machine, 6 axis for tool, 3 axis for extern rotary table.

Not sure I can follow you there. I don't see the need for U,V,W for work side rotations. Come to think of it I may have been confused myself by thinking we need to handle work side rotation differently from tool side rotation as I thought we would need to reverse the rotation direction. However the positive rotation is defined in respect to the tool rotation around the machine XYZ in either case.

I have created kinematic models with mixed work side and tool side rotations but my 'tilted work plane work' only dealt with machines with tool side rotation (primary C, secondary B or A). Maybe I'll find some time to expand on that.

So all other configurations, like xyzab, xyzac, xyza, etc need a different software approach.
And i think not all of these variants can use tooldirection optimalisation. Like xyza, where a is secondaire z axis.

For Gcode that was postprocessed to fit a specific kinematic  you need to account for the kinematic settings in the postprocessor (PP) to basically undo what the PP did AND you need to know the machine kinematics for the calculation of the rotary axis position to achieve the requested tool orientation.

If you decide to allow vector format Gcode then you only need to worry about kinematics for the calculation of the rotary axis position to achieve the requested tool orientation. This is why I suggested looking at vector (ie IJK) format as it's really the easier task.

However, the usual 4axis case will still likely still involve XYZA gcode. I think this would still work with the orientation path smoothing as it still creates a valid 3d curve that can be smoothed out to a G2 continuous  path. What happens if you feed your 5axis test a XYZA gcode (ie B and C angle values all zero)?

Note: I would interpret XYZA as a machine with linear cartesian XYZ axes and a rotary A (ie rotates the tool around the X axis). And again I _think_ that it is irrelevant whether A rotates the work or the tool.

  Then it should use correspondenting c++ function to translate gcode into the proper tcp, and other axis.
Like choosing kinematics.

Overall the current use of kinematic modules works quite well, except for the inability of the trajectory planner to catch axis limit violations in the look ahead and decelerate in a controlled manner before raising a sudden joint limit abort. This would be nice to have but would mean that the planner passes every motion segment through the custom kinematic module to check for limit violations before actually adding it to the queue.



 

Initial retrofit to LinuxCNC was done 3 or 4 years ago, now I am replacing servodrives (currently one 8i20 is installed and wired up) because originals have started to malfunction and show errors.
Currently I have not yet touched encoder wiring - old Yaskawa drives are still in machine and are exporting encoder signals to LinuxCNC. I do not think that there could be issues with encoder signal. The only change with servodrive wiring is that I have removed motor cable from the drive and attached it to 8i20.

Attached are INI and main HAL file. Relevant to 8i20 are sections of Z axis.
 
 

There are more other stuff in the servo that we think.. current pid loop(which we should called torque) is running xtimes faster then velo or pos loops.. when we want to run comm faster then 1ms, here we are on limits of servo loops itself .. we can see that in default setup of many servodrivers is this velo loop in most cases longer then 1ms and from my expreriences current loop are shorter then 1ms... 
​​​These regulator are pain to set correctly.. when somebody want to have FE in the nm, atmosferic conditions have to be constant(p,t, etc..) .. guys from kern machine has tolerances around um and there top of the world..

But there we are facing of kinematics limits of serial kinematics machines..

When you want to have precision below um, you have to use paralel kinematics ..

If you recently upgraded the develop version of probe basic and are getting an error,  copy the probe basic sim config custom_config.yml file to your machine config and overwrite your old machine custom_config.yml file to fix.   Be sure to adjust your display columns for the offset and tool tables.  We had to make some changes to resolve the most recent vtk updates and this required a change in yaml.

Thanks and sorry for any hiccups!

Chris

The config.txt is not directly under boot, its there you'll have to look you don't need to create one. Have a look under /boot/broadcom

That's the problem, the config file is not in the /boot folder. I created a new one with the SPI=on instruction and it doesn't even work. I don't know if this config file is not in /boot but in another subdirectory.

The Linuxcnx version uses the raspbian kernel sources, so it is possible to enable the SPI interface on the RP4. The config.txt file is not in the same location as on a raspbian install, it's still under a sub directory of boot.
The raspbian kernel is patched to allow loading of overlays, the mainline is not.
Modify your config.txt file, reboot and look under the /dev folder for spidev.xx files and they will be there.
I've used rod images and made my own images using the same tools,for testing a diy mesa 7c81 and know that it does work.

We made sure that SPI did work, at least on the RPi4, the RPi5 is a different kettle of fish.

Thanks I'll give all this a try, I'm not wired single ended at present.

1. Make sure you wire the TB6600 in single ended mode:

7I96S GND --> TB6600 PUL-,DIR-
7I96S STEP+ --> TB6600 PUL+
7I96S DIR+ --> TB6600 DIR+
 
If you don't want to double any wires
(like GND in the above example) you can:

7I96S GND --> TB6600 PUL-
7I96S STEP+ --> TB6600 PUL+
7I96S +5V --> TB6600 DIR+
7I96S DIR- --> TB6600 DIR-


2. The TB6600 has very slow inputs, it will not see a 2 usec
(2000 ns) step pulse. I would try 20 usec (20000 ns).