Advanced Search

So no need for the tool table to populate?  I think I have it running correct now....I was able to have a long reference tool to establish a G54 offset, I called a TXM6 for a short tool, and with that short tool I called it back to G54 and it hit the z target correct.  As long as I know not to look for a tool in the tool table I think I good for this part unless you think I am missing anything?

On a side note, I have another switch wired up to set my z offset "my G54" that is mobile, meaning I can set it anywhere on the table to establish my initial z offset, but I don't know where to find the code or how to initiate the probing cycle to make that happen, can someone point me in a direction to make that happen?  

Thanks again for all the help!!!!!  I'm excited to get this thing working!!!!!!!
 

Here you go

github.com/remora-cnc/Remora-STM32H7xx-PIO

It even has TMC5160 support. Work has slowed a bit as we're porting over the F4, but the H7 is running.

The A and B channels should be connected to PE9 and PE11, index to PE13. So that looks correct. It should work, but I have not played with the QEI for ages.

Thanks both on suggestions, I see, checked both links quickly.
Have a question on principal level.
I need to have in fpga both uart component and quadrature enc component.
In order to work enc reading, first enc input pins should be connected to fpga input uart pins and then via some logic/demux this pins needs to be routed to quadrature logic in order to get inc pulses and also there is need to issue select signals on this demux after uart transfer sequence is finished.
Or other way, enc pins are connected to both uart and quadrature module components inside fpga but enable signals of both components are separately controlled via some conditions/logic.
Is this working this way or?

The SKR1.4 and LPC1768 are legacy and not supported in the latest version of the Remora component. You could try to use an older version of the component that supports the LPC1768.

Tool offset is set here:
If this is run at every tool change then there may be no need to write the offset to the tool table.

Does LinuxCNC complain about latency issues when running?
What does
ip a
in a terminal return?
Upload here the hal and ini files so we can have a look.

I have a problem that I can't solve.

I replaced the Ethernet network card with an Intel one. At first everything seemed to be working fine, but then I started getting “joint tracking error” problems. LinuxCNC simply stops the machine.

I increased SERVO_PERIOD in the INI from 1000000 to 4000000 (I can't increase it any further, LinuxCNC won't let me exit emergency mode).

When I move the axes quickly with the arrow keys, it seems to respond better, but it still stops.

What could be the problem? The PC is new with an Intel I5. Only LinuxCNC is in use, nothing else is running. Everything is disabled in the BIOS.

It's causing me serious mental problems

Philip wrote:

G53 G0 Z0
 

Is Z=0 in machine coordinates inside the axis limits? If your soft-limit is at zero then possibly going to exactly zero triggers the error (I have a vague memory that this was a fixed bug, though). 

You could try setting max Z (or joint 2) to 0.01  (or whatever) then see if G53 Z0 still gives a fault. 
 

NickyDoes wrote:

My thought is to write HAL components to interface LinuxCNC pins to Logosol's LDCN protocol. The servo drives run a 51.2 microsecond update rate, so 20 servo ticks is 1.024 ms. 

What bit rate is that at? 115200 bps is quite quick for RS485 (though the internet suggests that 42Mb/s is possible).

At 115200bps 51µs per packet only has space for 6 bits of data, so it either must be running unusually high bit rates or not updating as fast as suggested.

Thank you, 

That would make sense, the G10 would populate the tool table and the G43 would assign the tool length offset.  I guess the mystery is where to add it to this ngc file?  And how did others have success with this code without those commands?   As you can tell I am really new to all this.  Attached is the sub routine I have been trying if you feel like looking at it.




 

You may need one of the G10 variants in your macro.
linuxcnc.org/docs/stable/html/gcode/g-code.html#gcode:g10-l0
Or possibly just a G43

Hi andypugh, jc2ktr shared his working setup, but here is mine:

Thank you for the response,

I am using Axis gui with version 2.9.4.  I was using this format (debug,#<5081>) which yielded ######.  Upon your suggestion I tried this format (debug, 5181) which yielded the number in the var file....a big thank you for that clarification!!!! 

I think my main problem is that my tool table is not updated based on my 5063 variable.  When the probe trips the switch, I see the var file up updated, it stores tripped the z value in the 5063 variable, but that number is not populated in the tool table.  As a side note, I did have to add the 5063 variable manually to the var file.

Again, thank you for you time
 

It's pretty much the same. It's actually fairly straight forward once you get the hang of it but I guess that's true for everything and I must have made a couple dozen sim models by now.
ProbeBasic has machine simulation that can be setup using a yaml file (similar to what some CAM systems have) but it is quite limited compared to vismach.