Juste quelque mA. Par exemple depuis 5V avec 1,5 kOhm en série.
Continuons  si nécessaire dans  forum.linuxcnc.org/46-francais

Robert

Ahhh thank you, I completely missed the G0 missing from the line after g33.1

You need to 'cancel' G33.1,  a G0 or G1 on the next line will help

My soft limits are not working all the time. Machine is running over them to hard limit switch. When I back off machine from hard limit switch soft limit will work until next startup.

I will read through it and will certainly have questions, which I will then ask here.
Thanks in advance.
Best regards, Mücke 

@Hakan:

I would always home using the encoder index (Z-pulse) if it’s available, since it’s the most accurate and repeatable method. When the index is latched close to the encoder or in the drive, homing accuracy is essentially independent of fieldbus or servo latency. I use it with the Probe Basic and it works perfect

You are absolutly right! For probing, the usual and sensible approach is a two-step process:

Fast search pass to find the edge
Even with e.g. 3-4 servo cycles of delay (≈4 ms), probing can be much faster than often assumed.
If you allow 1 mm total overtravel, including braking, and assume a realistic probing deceleration of about 1000 mm/s², the maximum safe speed is still around 40 mm/s ≈ 2450 mm/min.

Slow precision pass
After backing off, the second pass is done very slowly, typically 0.5–1 mm/s.
With a 4 ms delay, this corresponds to only 2–4 µm of additional travel due to latency. At that point, accuracy is dominated by machine repeatability and machine stiffness, not bus or servo delay.

So in short:
Homing: use encoder index --> highest accuracy, latency-independent
Probing: fast find + slow precision pass --> latency is not a practical limitation if speeds are chosen sensibly

Latency really only becomes an issue if someone tries to do single-pass, high-speed precision probing, which is not standard practice anyway.

Good Afternoon all,

I have the below snippet of Gcode in a larger program, LinuxCNC gives me an error saying that K word missing for G33/G33.1 when i load or run the program.  However, the G33.1 is used on its own in a simple program or in MDI and it works fine.  The program also runs correctly but halts after the g33.1 and does not go back home or switch spindle off etc.

Any thoughts from those more knowledgable in this area?

[code
]N84 T30 M6 G43
N86 G90
N88 M8
N89 S500 M3
N90 G0 X0.0 Z15.0
N91 G0 Z5.0
N94 G33.1 Z-14.5 K1.058
N95 Z15.0
N96 M9
N97 M5
N98 G53 G0 X0.
N99 G53 G0 Z0.
N100 M30
[/code]

 
 

That looks OK but unless the low level signal is < 0.8V it cannot work.

That is, this is a hardware/interfacing issue.

The 7C81 inputs are fine with 5V signals but 1.8V is an indeterminate level
for the TTL level signals that the 7C81 expects

Do you have a data sheet for the encoder?


 

royka wrote:

Sorry for the late reply, that image should also work for de OPI5 plus if you only edit in "armbianEnv.txt" the line:
fdtfile=rockchip/rk3588s-orangepi-5.dtb
to:
fdtfile=rockchip/rk3588-orangepi-5-plus.dtb

No it's wont boot (

Yes, I think its realistic to write a new firmware. The goal would be to have the pendant fully reliable and also proper detection if the RF link fails, possibly some other improvements as well.

It doesn't have to be an either/or solution. With the new firmware, I would probably strive to maintain "protocol compatibility", so the same xhc-whb04b-6 component could still be used.

Improving the xhc-whb04b-6 component is certainly possible, and hopefully that could be done as well. For this blocking wait state, I don't really see a clean/simple fix, other than reducing the max blocking time like we have done. And to be honest, the amount of abstractions used in the code makes it difficult to follow for myself.

But this is also one reason why I made this post. To see if others have similar issues (and now you have confirmed that its not only me). Maybe there is somebody else that wouldn't mind updating the xhc-whb04b-6 code, but would need inputs on what to change.

HI PCW
Please be so kind as to provide firmware for a 7i92T + 7i77 + 7i85

Thanks
Henk

Hello
I'm trying to retrofit a friends 5 axis machine (XYYZB) and I'm testing out the example config. The B axis on the nachine is mounted on the Z axis and I would like to visualize this. The thing is the example configs for non-trivial kinematics are based on rotary tables. The principle should work for this macine but I would love to make Gmoccapy show the tool tilting. Since examples use rotary tables the tool is mostly vertical and doesn't move (the table moves).
How can i change this?
Thank you

Hi I have difficults to use terminal its a little bit over my competens in linux ,but I change the cordless mouse to a mouse with a cord and after this the program are esier to work with the most off lagging diasapeard and I also changesd the Base period to 150000 and the Servo_period to 1200000 , after that i open up the idex setup file and set it to setp lowpass.0.gain 0.01 .

Its work great two weeks until today when the program freez again , after hard reboot it starts again .
One strange thing is during running a program nothing happens but if I take a coffebreak and the program idle the famos latensy varning came up on the screen . yors sinserly Krister

Hi, 
In PLC-controlled systems, there is a watchdog for each servo controller. This is triggered if the servo does not respond within a specified time.  The same is done with pneumatic cylinders. Here, a timer is started in parallel with the cylinder stroke. If the timer is faster than the cylinder in its end position, there is an error.
The same could be done for homing.
Isn't there a control bit in register 6041h that is set when the servo starts homing? For example, bit 4 or bit 9. I don't know, you would have to visualize the bits. 
If you find such a bit, you could combine it with a watchdog.