Advanced Search

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

Mars wrote:

* I have asked on the Remora part of the forum if the RP2040 based system (which sounds great!) is ready for prime time and I have had no responses since posting it a couple of weeks ago.  Is the impression I am left with which is that it is not ready and the enthusiam for it has died out?  
 

I saw your post on the in the Remora forum a week ago. I think that the port to RP2040 is not as developed as other port; one reason is probably that there are only few 3D printer control boards based on this mcu. As Scotta wrote in the post:

scotta post=344968 userid=24854

"This Remora port was a hotel room project when I was travelling for work."

I played a bit with it, mainly because I had some rp2040 around, but never used it to move physical axis. That's the next thing; if you want to interact with real world, a Pico might not be enough. You'll need some buffer and optocouplers. And this is something you get out of the box with the Mesa card. I guess you could also try the PicoCNC board designed for grblHAL and put Remora on it, but it's not that cheap anymore either.

For the RP2040 there's also a component called stepper-ninja that might interest you. But again, you'll not find the maturity of Mesa cards there. Really depends what you plan to do with it.

And if you go with a RPi, yo can also design a HAT for it with some SPI drivers; I designed one with TMC5160 drivers on the top and wrote a LinuxCNC component to send target velocity over SPI; I probably wouldn't use this as is on a CNC mill, but I have a Galvo Laser engraver that is mounted on a 3 axis system, which are connected to that HAT. It's been a year now and never had issue with it, but I only use it more or less an hour per week.