Is this QTPlasmac Expected behaviour - Cycle Start and Jog disabled.
From what a vaguely recall, i did some test and had no success of pinpointing it.
This sort of issues are lingering on from PlasmaC where it would run several cuts then stop at random and do nothing, requiring stopping the machine and using "run from here" to continue.
PhillC did find the issue but apparently not the exact source of the issue, the Z axis would not retract to set height and remain waiting, did fix it to a certain extent where it was very usable and happening rarely.
QtPlasmaC has another similar issue, where running a program would start, got to pierce coordinates and wait there indefinitely despite Z axis being at the correct height. This happened in PlasmaC about once or twice in a full days work, on QtPlasmaC happens way more often, sometimes 3 to 5 times per sheet.
I have not experienced this behavior on a physical machine, however I can reproduce similar in my QtPlasmaC Simulation environment. In my case, it happens when eoffset movement would exceed the available range of travel (usually in Z). I have to deliberately force what I consider to be unrealistic values (but may not be for every table/setup) to trigger it. If you encounter this again, please check the following HAL pin and report back:
motion.eoffset-limitedIf this pin is TRUE, that may explain what is going on. My recent changes to automatically adjust probe height based on material thickness made this more visible. I plan to add some bounds checking in the component with regard to eoffsets, and likely will also monitor the aforementioned pin a general catch-all fault condition.
All this is way past being important, i did voice my concerns during the development about not implementing useless features into it and PhillC ignored most of it to the point that i recused myself from participating anymore, it was disheartening to see:
-PhillC sabotaging his work by implementing useless features, always, always requested by users with a single plasma machine and mostly no or little experience
-my complaints being ignored, while i had over 15 machines in daily use
With regard to your broader concerns, I am not certain which specific changes you are referring to, but many valuable contributions have come from users with only one single table. It is relatively uncommon for contributors to be building machines commercially, and practical feedback from small shops has historically been an important part of Qt/PlasmaC’s evolution.
-my input about the functionality being ignored completely, like : float switch MUST react and stop the machine even during jogging, this has ruined many torches and would have ruined much more if they did not have magnetic holders.
This functionality is in the PlasmaC component. The float switch (along with breakaway and ohmic) inhibits jogging when the machine is Idle.
github.com/LinuxCNC/linuxcnc/blob/2078bd...ts/plasmac.comp#L908
Excerpt (sensor_active is the result of if(breakaway || float_switch || ohmic_detected)):
/* set jog inhibit if required */
if(sensor_active && program_is_idle && !(override_jog || state == PROBE_DOWN || state == PROBE_UP)){
jog_inhibit = TRUE;
}else{
jog_inhibit = FALSE;
}Appears to be in both 2.9 and 2.10.
-UP/DOWN/ARC_ON LED's on the main screen MUST be usable even while not cutting to check standalone THC's like Proma
I've never seen this request but it would be straightforward to implement. I'll add it to my list of upcoming changes. Initial thoughts for criteria would be Machine On and Idle (not available when the GUI is off, or if the machine is paused).
-seeing all the effort made by PhillC and later you going to waste as PlasmaC and QtPlasmaC got so bloated and so unreliable that i had to stop using QtPlasmaC completely, and actually thinking of slowly moving the remaining PlasmaC machines to my old hal THC stuff, that never fails, ever. Yes, PlasmaC is usable and mostly reliable
-etc etc
-
I disagree with the characterization of PlasmaC/QtPlasmaC as bloated or unreliable. There are multiple real-world installations running successfully, including commercial operations.
Sorry Snowwy and Phill, but i have discussed this before with both of you, even on the phone, so to recap, this is not fixable, must be started over.
I was not trying to pick a fight.
I was not privy to you and Phill's telephone call(s), but in fairness to both Phill and myself, we've both asked you to post a backup of your configuration to try to help pinpoint the root cause, several times. If I recall correctly (not always reliable
), I even emailed you on the side asking for it in case you weren't posting in fear of leaking any sort of Intellectual Property.As a developer it's not that I don't believe you're having an issue, it's that it is insanely difficult to pinpoint a cause and try to fix it when we are unable to duplicate it. This thread, and the changes made to the component are proof that your concerns were not just brushed off.
There are times like the recent PlasmaC issue I closed out where it was, in fact, the user's configuration that was causing the issues...
Please Log in or Create an account to join the conversation.