Advanced Search

Moved, thank you Chris.

Thank you for your detailed answers; i have ordered RS422-TTL converters to try everything out as soon as possible.

I checked the stepdir generator again in Verilog/GTKWave and tested a few edge cases.
I noticed that a pulse can be strtched if the velocity drops to 0 at the wrong moment, so I fixed that.
But that shouldn't have anything to do with your problem; it's more of a cosmetic change than a bug fix.
(in the dev branch)

can you post your json config please, i will check it.
you can also try to invert the step pulse in rio, maybe thats the problem.

Another possible cause could be that the deadband value is too high. Does the zero position drift, or does it remain stable with the same offset? How large is the deviation from the actual zero point (approximately 1, 10, 100, or 1,000 steps)?

My tests on both the ICEBreakerV1.0e and Tana Nano9k yielded the same results, not due to the FPGA brand, noise, or settings.
I noticed that the Dir PIN output returns to its original position after the step action is completed. This may be because the DIR operation is not yet complete, but the STEP operation occurs prematurely, causing an error.

No, but I can make one tomorrow.

7I92 or 7I92T?

 

Another possibility is marginal timing.

Either too narrow step pulse widths,
or insufficient setup times from DIR change to
STEP or insufficient hold times from STEP
to DIR change.

Hi, PCW
Is there available firmware, for the configuration: 7i92 + 7i76U_pktv3d.bin  ?
I need to use the modbus characteristics of 7i76U 
Thanks, in advance.

You are in the wrong topic. Probe basic is a QtPyVCP project not QtVCP.

You'll get better response there.

1. interference due to bad/not shielded/grounded cabling
2. marginal output signals for the drive optocouplers
3. Tango skipping steps, although LinuxCNC is very good at avoiding this, tango might not be, or LinuxCNC might not be aware that is happening.
Does this also happen at very low feeds/speeds?

I'm using the DM542 Microstep Driver shown in the photo, with a Tango Nano 9k FPGA. After executing a set of gcode in Linux CNC, there's an error in returning to the zero-point position. However, I can correctly return to the zero-point position using a Mesa7i92.

 
 
 
 

Have patch waiting to merge to silence those.

We have been stuck on the feed override for TP2, doing it proper without any jerk spikes, is proving much harder than we thought.

Hi everyone,

I'm new, so go easy on me.  My team is using Probe Basic as a GUI for a 5-axis CNC Mill.  We're trying to create a cutaway button that will show only half of a part at a time.  It will virtually slice the part and show the cutaway.  After some google earching, it looks like this is not a common request.  How should we go about doing this?  What is the best route to take?

Thanks,

Dan

here the zipped config.. hope it help us... thank you for the help and time and headache

i have a RPI-4 running linuxcnc 2.9.10. using  a 7i96s, the qtdragon GUI, and inductive proximity switches. i have one switch acting as both home and limit.
everything is working perfectly except for a minor annoyance on the status bar. when i home, and the axis move toward the home switch, initially trips the switch, it properly reverses off the switch (search velocity is positive, and latch velocity is negative so the axis is of the switch), then continues on to the final home position. but when it initially hits the switch, the status bar shows "hard limit tripped". the machine doesn't stop, so it is properly ignoring limits while homing. the fault clears itself after several seconds. just curious why this is happening. i thought i read somewhere that it re-enabled limits after the cycle was done, apparently not the case? I assume if it bothers me enough i could learn/write some HAL code to block it in the GUI?? or better yet just use the switch as home, and just rely on the soft limits