Advanced Search

Hi,

regarding qtdragon_hd:
are the Touchoff Parameters in the Settings Tab redundant to the settings in basicprobe resp. versa_probe?
E.g.
basic_probe  "PROBE RAPID" and "PROBE SEARCH" sounds like settings "SEARCH VELOCITY" and "PROBE VELOCITY".

Kind regards
Carsten

There is a problem with this image! I've been at this for weeks

What exactly are your symptoms you are having that suggest you you that you need a stronger stepper? Are you merely randomly loosing steps? Staling? At what speeds are you experiencing stalls? Are you sure you don't have a mechanical issue causing binding of the Z axis? Are you using suitable step rates and step timings? At what motor RPM is your maximum feed rate?

If your max feed rate is such that your motor must turn much more than about 1500RPM, then you are probably going to have to lower your max feed expectations.

If you are having trouble with stalling when the motor RPM is greater than 500RPM but is fine at low RPM then you might be able to get away with simply increasing your voltage supplied to your drives. (Assuming you can do so without exceeding drive's voltage limits.

If you are merely loosing random steps here and there, (usually resulting in the Z position slowly loosing height, the most likely culprit is poor step pulse timing (too short pulses) and or electrical communication issues between the control and drive (electrical noise).

If you are getting random stalling at any speed, and you are certain there isn't a mechanical issue causing binding, and slowing the acceleration and max velocity doesn't help. Then you are probably going to have to resort to replacing the motor with a more powerful one. This will almost certainly require replacing the stepper drive with a more powerful one as well. If either the existing drive or motor is undersized for the other, replacing the smaller of the two with one more appropriately sized for the other could be enough to increase your performance. But usually you will need to replace both to see any significant improvement, this may also require you to switch to a larger power-supply

If you are replacing drive and motor, switching to a closed loop stepper system would probably be beneficial and would require no change to the existing control system whether that would be Mach3, Linuxcnc, or something else. (It would still use the same step/dir signals your existing system does.) Provided you configure the new drives to use the same micro-step settings as the old one.

rodw wrote:

So here are the remaining issues:
1. Torch Breakaway does not pause motion when triggered despite the plasmac.breakaway pin going true
2. recovery panel is never displayed. I thought it might be linked to not having a M52 P1 but that is not it
3. If paused, it cannot resume until Linuxcnc is restarted
4. Safe height is ignored. Rapid Traverses are at max height

Its a long time sice I have used qtplasmac but these do appear to be bugs to me.
Any help or ideas will be appreciated.
The config is in git here github.com/rodw-au/showstopper

2.9.3 isn't quite helpful because it's difficult to find the line in the sand and correlate it to a version of QtPlasmaC. Even if you used the buildbot, it's been down for months, so who knows where you stand version wise.

The repo is neat, but it would be more helpful if you could post a backup of the config that was created by QtPlasmaC. It contains a few more "extras" that may help us track down issues that aren't present in the config folder otherwise. First of which is the specific version.

At any rate, I did checkout and build 2.9, and I don't see issues 1-3. Grated, it would be the latest version of QtPlasmaC which is 2.9-238.315, and I also didn't simulate your config ... but from what I see here QtPlasmaC is working.

I don't see issue 4 either, even on the VM, I can see that it's obeying my safe height of 0.75". In the picture below, Max Height is obviously where the cut started from. Remember that safe height is measured from the top of the material up. linuxcnc.org/docs/devel/html/plasma/qtpl...plasma:initial-setup

 


Reading how much you like being on the "bleeding edge", I'm a drop curious why you didn't use the master branch? It does have a few more features that are not present in 2.9. It's also noteworthy to mention that at this point, 2.9 is considered "end of life" from a development standpoint (to include bug fixes).

bertoldo wrote:

try mont the image... is wrong
 

It did the same to me, I think the SD is dead

try mont the image... is wrong

Good afternoon jjdege, it loads there... but try to open or mount this image on your computer and you will see that it says it is corrupted. This process with raspberry image loads on the card without errors but when executing it gives errors. There is a problem with this image.

bertoldo wrote:

Thanks for the answer.
but the issue I see and that makes me suspicious is that I download the image on a PC with W10 and I can't open it. It says it's corrupted, I can't even open it.
 

Hi
I did a test:
I downloaded the image from here with W10
I opened it with Raspberry Image

 

it loads without problems

If one interprets the explanation of #5210's function as being "disable G52 & G92 offsets", then it's perfectly appropriate to use it they way they did.

I certainly hope there is no such wording in any of the documentation.

[edit]
As an illustration here is what 'G92.2' does (setting #5210 happens in this line 'pars[5210] = 0.0;'):
 

If one interprets the explanation of #5210's function as being "disable G52 & G92 offsets", then it's perfectly appropriate to use it they way they did.

Assuming we're right about the fact that it's a flag (not a switch), my suspicion is that the ATC subroutine author(s) simply misinterpreted the purpose of #5210.

 

I'll have to test this out and see if manually zeroing #5210 changes applied G52/92 offsets.

The problem with things like this is that it may work fine for 99% of the configs but cause inexplicable behavior for the other 1%. The simple fact that this gets the python status channel out of sync would be enough for me to reject this solution. It seems strange that '#5210 = 0' was chosen rather than 'G92.2' particularly since these are used in MDI commands and ngc routines.

Looks like I asked this question a couple years ago.  Memory failing.

forum.linuxcnc.org/qtpyvcp/46414-probe-b...eter-question#247625

If #5210 is intended (in LCNC) to be a 'flag' which indicates a G52/92 offset is applied, then writing to #5210 directly seems to be the wrong way to clear offsets.  And may, in fact, not clear out any offsets.

If the PB toolchange intention is to disable G52 or G92 offsets, G92.2 (or 92.1) could be called in the subroutine and a check for #5210 = 0 could be made to ensure the offsets are cleared.

Or a comparison made: if #5210 = 1, then G92.2 (or something like that).

I'll have to test this out and see if manually zeroing #5210 changes applied G52/92 offsets.

Ok, this is a wierd one.   I have a Hurco KM3P mill with automatic speed control.  I'm moving to linuxcnc from factory controls.
The spindle is driven by a standard 3 phase motor and a servo that runs the reeves speed reduction in addition to a standard bridgeport type backgear selection.  I want to abandon the backgear, and just run on the slow speed geartrain, and use the reeves drive for the first part of the speed range, then once it's maxed out, use the VFD drive to get the remainder of the spindle speed up to 4000rpm.  So i'm thinking there must be a way to do this.  Probably write a module?   Anyone done anything like this before?

Trying to avoid screwing with the manual backgear selection depending on spindle desired speed.  It's literally the only manual selection on the whole mill.

Thanks for the answer.
but the issue I see and that makes me suspicious is that I download the image on a PC with W10 and I can't open it. It says it's corrupted, I can't even open it.

bertoldo wrote:

Good morning!

I am using the image from the link that started the forum about ethercat. My raspberry has 8 gigabytes and a 64 gigabyte SD card... and I use the raspberry image to generate the boot. I downloaded this file from the link you sent me now and the error is the same. If I try to open the image, it says that the file is corrupted.
 

 

Hello
the micro SD is very fragile, nothing is enough and it is no longer usable,
the installation with Raspberry Image is successful but the system does not start, I burned three,
with the installation directly on NVMe M2 and adapter
in my case, I solved it, I do not know if the problem is the same
I reinstalled several times without problems