Advanced Search

I had nothing but problems with my Vers WLR probes. I had 4 different probes ranging from v2 to v7 and all had intermittent receiver and trigger issues. I gave up on them even though I really wish they would work. There isn't another wireless probe in that price range that I know of. Not sure if you are experiencing any of the same issues but the odd behavior (especially #2) sounded like the problems I had.

Ok made progress I can load a G-code created with EstlCam and move the table to any location and touch off and run the g-code without a problem.  I cannot load or run a G-code created with SheetCam even with a NGC file type.  I did some changing in the INI file and had other errors, I attached some PDF files with info and screen shots of the error messages I got and the 2 NGC files.
Thanks for your time hope you have more good info in a reply.
 
 
 
 
 
 

Thanks for chiming in.

I don't have a debounce (or dbounce) component in the probe loop, but I'm not sure if I need it.  I'm using a wireless probe (Vers. WLR v2) and I think the actual probe signal is debounced before the receiver sends the signal on to LCNC.

Could be wrong though.  I'll try direct-connecting the probe to the receiver (via cable) tonight and see if eliminating the 'wireless' part changes anything.

The frustrating thing is that the errors are intermittent, and I don't want to raise an issue on GH until I know for certain there's a subroutine error (and I suspect there isn't).

7I80HD-16 and -25 versions of 7i48_7i52 firmware:

 
 

I think the remora w5500 firmware is only for stm32, and not for the LPC1768/9

RLA wrote:

Hi...so one more question...I was thinking to drive 2 tools off same axis from computer...the only thing is that they have different scales..meaning one is screw...other is gear....almost 10 to 1 difference...I was thinking of using 2 different drivers with different microstepping...does not seem to work...any other workarounds?

Thanks,

Rick
 

It most certainly can work. But you may need to be a bit clever, and not do everything in the conventional fashion. I recently set up a gang-router that uses 8 independent joints for 8 independent Z axis spindles. While the config I made does have each of the spindle joints using the same motors, and screws with the same pitches. Nothing in that configuration would preclude any of them from having different scales. Each of those spindle joints have their own independent scale settings.

It's not that the future of this forum is really a community decision but there have been offers to try to migrate it (just like the buildbot infrastructure), no one has ever been taken up on it.

Generally the whole project is running on aging volunteers maintaining aging infrastructure. Whether it's the forum, the buildbot, the wiki, or the source code itself.

In my opinion, if somebody wants to modernize anything they will (most likely) simply have to setup something and see if the crowd follows.

It has been quite a number of years since the forum was last updated. However I feel that the forum user interface seemed much less buggy to me as an end user before that upgrade. I'm guessing that the pain of the last redo has very much discouraged anyone from attempting it again.

1. The runaway suggests loss of encoder counts/rotor synchronization (after the oscillation)
oscillation is likely too much P or too low D

2. For torque mode drives a significant amount of the tuning is with FF2

3. P tuning is done only after you have the maximum stable D term


 

cakeslob wrote:

tommylight wrote:

What GUI?
Every GUI that existed in 2.5 should exist in 2.9 and much more....
If you want to have stuff saved to USB, google "debian 12 persistence usb"

mini and keystick were axed after 2.7

I was not aware of that, thank you very much.

I use Probe Basic exclusively but I'm about 2-3 months behind on updates at the moment.

Haven't come across the errors you describe but I did have to add a debounce filter with a delay of 10.

I've been following the QtPyVCP and Probe Basic changelogs on GitHub and if my memory serves me right there has been some probing related changes in the past few months. Maybe Lcvette or TurBoss can figure out why you are seeing this behavior.

Tinine wrote:

The best single-chip solution for motion control is without doubt The P2 Propeller 64 "smartpins" (all can decode quad @ sysclock/4 with no impact on any of the 8 identical cores) any pin can be a 16bit DAC, etc.

For the price, i always will choose Mesa, the fact it has 16 bit DAC is nice but still Mesa support wins.
It is good, though, for sure.

As far as I understand it as long as they're part 107 licensed and have a laanc authorization they can fly almost anywhere
unless it's highly restricted airspace. The homeowners have no say over the matter. It's frustrating to say the least.

I fixed it, but probably not in the easiest way. I completely rebuild my *.ui file with the designer, but used the designer on the new pc instead. Screens look the same, use the same widgets and now the UI runs.
Loading a *.ui made on a older version apparently is not backwards compatible...

After the ui finally loaded I ran into other issues. Took me a while to find what was causing that. Turned out my existing python user scripts refused to run. To fix that the first line in the *.py files needed to be changed from:
#!/usr/bin/env python
to
#!/usr/bin/env python3
also I changed the rights to the python files with chmod u+x

After that the scripts ran without any problems.

tommylight wrote:

What GUI?
Every GUI that existed in 2.5 should exist in 2.9 and much more....
If you want to have stuff saved to USB, google "debian 12 persistence usb"

mini and keystick were axed after 2.7