Advanced Search

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

Hello Guys!

Finally I have some updates !
The linear scales are working! Note to my selfe: dont trust anyone in the internet. 
I will make a sheet, where I will draw up the connection between the exe and the mesacard. Next on the list are the endswiches and the e stop. Hopefully it will move on its own by the end of the week. 

Here a pictue of the conector of the exe:
 

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

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.

 

My God! What a moment !

Auto nesting finally, after a whole day of testing versions, virtual machines,etc
finally appeared.

Locale. Changed number, date etc format to English(US) and the Auto nesting window appeared.
Feel magic (although I should be made for such a rookie error on Sheetcam's part).
I won't change that on my desktop computer so I guess I continue with the VM for this.