GUI for PlasmaC - QtPlasmac

More
5 years 11 months ago #188170 by pinder
Replied by pinder on topic GUI for PlasmaC - QtPlasmac

rodw wrote: It would probably be useful to retain a GUI setting to disable it. I don't think I would ever disable it from gcode.

+1

Please Log in to join the conversation.

More
5 years 11 months ago #188176 by phillc54
A couple of shots of where I am at with the layout for the 16:9 Main and Parameter pages.

Main:
Warning: Spoiler!


Parameter:
Warning: Spoiler!

Please Log in to join the conversation.

More
5 years 11 months ago #188179 by tommylight
Looking nice! :)

Please Log in to join the conversation.

More
5 years 11 months ago #188206 by snowgoer540
This is really looking great!

Please Log in to join the conversation.

More
5 years 11 months ago #188245 by grijalvap
I tried to run it in a new 2.8 install and it didn't worked
first thing it claimed was dbounce component.
what version of linuxcnc are you using?

Please Log in to join the conversation.

More
5 years 11 months ago #188273 by phillc54
It is being developed on the Buster ISO with python3 and master branch.

I also have it running on the Stretch ISO with 2.8 and python2

The dbounce component was added in early September, it wouldn't be in the released 2.8 but would be in a Buildbot build.

Please Log in to join the conversation.

More
5 years 11 months ago #189764 by phillc54
A question for the guys using the Powermax communications:

Should the enable button for the powermax comms be:
  1. Enabled on startup
  2. Disabled on startup
  3. Determined by the last time the machine was used

Please Log in to join the conversation.

More
5 years 11 months ago #189768 by snowgoer540

phillc54 wrote: A question for the guys using the Powermax communications:

Should the enable button for the powermax comms be:

  1. Enabled on startup
  2. Disabled on startup
  3. Determined by the last time the machine was used


The current behavior is to remember the saved stated (I know you know this... just saying to remind others).

Personally speaking, there are a lot of times I fire the table up with 0 intention of cutting (testing, etc.) and I get annoyed at the popup. I don't want to save it in the "off" position because then I forget to turn it on when I actually go to cut. In these events I could see option 3 being convenient.

Will the error message be similar to how it is currently (if it's enabled and it can't communicate, it times out, gives a message, and disables itself)?

I think for me it would be a toss up between 1 and 3. When I do a lot of testing, it's nice for it to remember the state. That said, for all intents and purposes, it operates via option 1 (always enabled) currently since I never disable it and save the state.

If I had a table I used all the time to make money, or had an employee running it, I would want option 1 to ensure it always communicated.

My vote is option 1, dependent on the behavior if it can't connect.

One last thought, what about if it was option 3, but then before a program ran, if the user has PMX comms, but they are disabled when you press run, it gives you a warning that PMX comms are disabled? I know for the most part people hate dialog boxes, just was spit balling.

Please Log in to join the conversation.

More
5 years 11 months ago #189771 by phillc54

snowgoer540 wrote: Will the error message be similar to how it is currently (if it's enabled and it can't communicate, it times out, gives a message, and disables itself)?

Yes

Please Log in to join the conversation.

More
5 years 11 months ago #189773 by snowgoer540

phillc54 wrote:

snowgoer540 wrote: Will the error message be similar to how it is currently (if it's enabled and it can't communicate, it times out, gives a message, and disables itself)?

Yes


Sweet. Amended rambling post: I choose Option 1.

Please Log in to join the conversation.

Time to create page: 0.491 seconds
Powered by Kunena Forum