Advanced Search

Moved to "QTPyVCP" section.
Thank you.

Good point on hot stuff up top. I’ll definitely be switching that up! So far I’ve only got the one power supply that was left over from another project, so I’m not opposed to switching them out at all.

Great news! Glad you got it sorted! 25 is a bit fast for small holes, I would recommend finding a balance to be able to achieve full acceleration in small holes to ensure the probe event is at speed for best consistency. But finding the sweet spot is easy now that you're not getting errors.

Power supplies & VFD up top
Then drives
Then controller and field IO at bottom.  Field IO cables exit through bottom of case with drip-legs.  Saves running lots of conductors all the way across the panel.

Vent the top of the enclosure if possible (i.e. add a chip/splash guard over the vent), or the top of the door if not possible.

Fans at bottom or top (intake or exhaust opposite fans).

I prefer a positive pressure airflow (fans at bottom) rather than negative-pressure, but that's splitting hairs.

Basically - heat-producing parts at top, controller and sensitive IO as far away from VFD's and noisy servos as possible.

And if you haven't bought them yet, I'd suggest using a big toroidal PS for the steppers rather than a bunch of switching supplies.

Hey All! First post here.  I've built a few plasma tables before, but I'm converting my first mill over.  Its an old lagun knee mill, I hadn't done all the research before I started buying components because I figured it couldn't be that much different from a plasma table but here we are and I bought closed loop steppers but wish I would've gone servos. 

But on to the actual point, I'm trying to build this box out really nice this time around, and am trying to plan it all as best I can before I start mounting and moving stuff 10 times.  I was hoping some of you with some experience might chime in and tell me if something I am doing is either just not going to work, or not optimal. 

 


Here's my list of parts:
VFD:  Mitsubishi D700
Controller: Mesa 7i96S
Stepper Drivers: CL86T Closed Loop Drivers (Stepper online)
Steppers: Nema  34 12 Nm
Din Relays (10) For eventual accessories (mist, air burst, power draw bar)
Power Supplies: 4 - 48v,  1 - 12v,  1 -5v
Breakers: 1 - 30 amp,  1 - 20 amp

The Mesa card will be up on the top row, leaving room for a daughterboard later if needed/wanted
I figured pneumatics should go in a second box to isolate in case of water.  
Only thing I'm really concerned about is if the VFD is ok to be that close to my controller.  Not sure if it'll cause any RF interference or anything.

Thanks for any advice!

LinuxCNC no longer supports Buster, the last Buster master branch build was July 6th.
buildbot.linuxcnc.org/dists/buster/maste...inary-amd64/?C=M;O=D

To get the latest master branch you would be better off "upgrading" to Bookworm, packages are available on the other buildbot:
buildbot2.highlab.com/

Having said that, it seems the other buildbot has not built master branch since Oct 5th...
 

Well that did the trick.

Removed the second slow probe, increased the fast probe speed to 8, and cut debounce back down to 2.

10 out of 10 clean probes!

Upped the speed to 25, re-calibrated, and it's still repeating perfectly.  Deviation between pocket probes is maybe 0.0001" 2 out of 10 sequential probes.  The other 8 of 10 are perfect repeats.

Even found a probe rotational position where X and Y are a perfect match.

Thanks a TON for the assistance.  Now I just need to figure out how to incorporate the probe's error signal in to the probing routines so it stops if the RF error is present during the probing.

Hi!

I am using QTPyVCP and would like to use my tool length sensor. My CNC Router is set up in a way that it home the Z-Axis to the maximum upper Point is the maximum travel. This means a few millimeter above my bed is Z=0. This way, my Z will always be positive. As I understand, when using the ToolLength sensor in QtPyVCP it has to be the other way round, is that correct?

When Setting up the toollength tool. I set up my Position 20 Millimeter above my Sensor ( Z=70mm). However when trying to probe it just plunges to Z=0 and then moving in X/Y to the Sensor position (shouldnt it be the other way round?).

Is there a way to make it run with my Axis directions? Or should I switch my Z=0 direction?

i'm not sure I understand " have the same pinout for the inputs" although I see the writing and all the same points have a connection as the drives in the probotix. I'll see if I can get a good picture of the BOB

Seems like there was an empty field/value where it was to have a value, so try to skip this part without changing anything, and if that works, go back and change one by one values you need and moving forward to test.

Hi Lcvette,

I didn't know linuxcnc would do this. When coding and testing i got my head scratched and thought : alien obstruction

not sure how to get around linuxcnc applying the G64 rules pre optimizer
Yes, indeed. We are screwed.

Tested this in top off a linuxcnc gcode file :
G64 P10 Motion blending tolerance
G61 Exact Path Mode
This then resolves the issue.

Wich means this is not applied :
when the maximum deviation of an arc from a straight line is less than the G64 Q- tolerance, the arc is broken into two lines (from start of arc to midpoint, and from midpoint to end).

Another error i was getting:
"same Y word..".
Cause, when running the "validation.ngc" file, when start is pressed, the file overwrites itself.
To avoid this, the filename now get a random number attached.

In the mean time, we learned a lot today.
 




 

RLA wrote:

...is it possible to set up different scales to same axis for different motors?

Yes.

Nice to see someone with commit rights move the ball forward with such initiative. Thanks.

nothing worse than being wrong about being wrong!..I thought it should work but when I tried it ..seemed not to...ended up being a stuck dip switch on driver...Now I was only using driver dip switch to get equal movements on 2 totally mechaicals...one a screw..the other gear...is it possible to set up different scales to same axis for different motors?

Thanks!!

Rick

BaxEDM wrote:

Took a different work around / approach. Instead of requiring my customers to set a max expected feedrate in their G-code, my new feedback control will require them to always set the feedrate to F1000. This is then the highest feedrate used for retractions. My feed control component then does the scaling stuff and estimating the optimal FRO value. This works nicely.

I did run into show stopper performance issues after switching to 2.9.3 and bookworm, I'll start a new topic for that.

I guess I am a little late here, I apologize I received the email response from Rob Ellenberg a few days ago but couldnt get back to this until now. I didnt see your work-around before I pushed a commit (github.com/LinuxCNC/linuxcnc/commit/0625...250a6cfb701303966f7e) to the master branch to change this for you. It would allow you to set the range for motion.adaptive-feed based upon the ini file's MAX_FEED_OVERRIDE value. This was chosen to play nice with the trajectory planner.

I had noted the following in the commit, but for the sake of closing the loop here and for those who dont read the commit notes, here's what Rob had to say:

As best I recall, I was preserving the existing behavior (it was likely limited to [0,1.0] before). That said, I don't think there's a fundamental reason it can't be greater than 1, though you'll get suboptimal lookahead behavior if you make it greater than the max feed scale value defined in the INI file. The TP creates the blend arcs with large enough radii to be smooth at maximum feed override. If you made the valid range [-max feed scale, max feed scale], I think it would be safe.

Perhaps this is better than the work around you concocted?