MonoKrom - QtPyVCP GUI for PlasmaC and Mill

Thanks replying snowgoer540.

My comment related to 2.9 and not plasmac in any form. In hindsight I should have been more specific, i was using a mill qtpyvcp gui I wrote/use. This gui has been used for over 6 months with no issues on 2.8. I happened to have reason to setup up a RIP install of linuxcnc and tried runnings things off HEAD. I performed a set of G0 commands via MDI and then left things running in idle A few minutes later the linuxcnc task seg faults. Perhaps I managed to find a point in time on 2.9pre that had some quirks. All i can say is 2.9pre (with the version of HEAD I had from within the last 24hrs) crashed for me and 2.8 under the same conditions didnt. Maybe I just got lucky, or is that unlucky? Now if there is a 2.9pre tag or commit I should be pulling to use instead of HEAD then very keen to know that.

I had come across mention of the external offsets “bug”. Would be interested to read what that was about, is there a link or search phrase that will pull that up without having to wade through hundreds of results?

Anyway back to my real question, is MonoKrom gui for plasma still being worked on?

Thanks - J.

Thanks Phil. I'm going to assume that my seg faults were random and perhaps caused by something else going on during that particular run of linux. Move forward using 2.9pre0 and keep an eye out for anything odd.

Lots to learn on QTPlasmac and a LOT of machine building work to do. Especially since Rod has thrown a spanner in the works and starting making a reasonable case for pursuing a vertical machine instead of dealing with a flip/folding table.

Cheers.

neat , i like the old fanuc style too, visualy solid and simple.

Do you have plans on adding a rotary axis?


I will try this ASAP.


Regards

Meth

I have started doing some tinkering on Monokrom Plasma adding in UI elements and working out the HAL connections needed to operate with the plasmac component.

Some work being done on the run and config screens. Moving to a process centric view of cut parameters.  Backed but a sql backend so this could be local to a single machine using sqllite or it could be referencing a single DB source in a shop with multiple tables that all reference off a master DB (MS-Sql, MySQL, Postgress etc etc).

Also starting to leverage the qtpyvcp framework to expose many of the params as hal pins so they can easily "wired" to the plasmac component.  Obviously still WIP as the hole and slot detection areas are placeholders. Although the hole detection is represented in the persistance layer.

Cheers - J.

 

 

Looking really good JoCo
Great to see some big picture thinking around materials/process parameters.
We'd need a way to lock or hide  the machine selection (by an ini file variable?) so it can't be changed accidentally.
Can the parameters tab be accessed while running a job? The ability to change probing parameter and some other settings while running is really needed.

We also need room for more buttons. Things that spring to mind are park, framing, laser control etc. Possibly there is another tab in the control section to make room for them. This might also include sheet alignment settings.
 

Re locking settings: yes a good point. I would expect the distance/pressure systems and machine to be locked and taken from the tables ini file.

Nothing stopping this tab being accessed during a run.  Although if there are specific values that we would want quickly available to dynamically tweak during a running program then I think putting them on the main screen might be ideal.

Space is always at a premium.  I have gone for size and spacing to better support old eyes and big fingers.  The screen size on this is not large. That layout is running at 1283 x 946.   If you have a 1080p monitor then there is masses more space to do things with.  However I have been trying to keep things reasonably tight. This is a little over WXGA res. Any advice on a minim res that would be reasonable without creating a silly squish that would be great.  Then at least we can all understand the limitations driving any design compromises.

On the extra buttons, we can add in extra tabs to provide more screen space.  We just need to decide what sensible groups of activity would be. Some groupings will be workflow related where that stage of the process is done then not touched again until the next job is setup.  Others might have aspects that we want to be easily tweaked during a cut.

Not yet having a running table I will take all the advice on what needs to be grouped how. 

Cheers - James.
 

Re: Locking settings.
I would like to add user login levels that lock out certain settings depending on the user.

On *day job* machine control we have levels 1-10, with 1 being the level that a temp laborer would have. This would allow programs to be selected and ran, but not edited or the machine jogged or settings changed. Level 5 would be a standard high level operator, level 7 would be maintenance/manager level with most things opened up, and level 10 would be OEM specific settings like drive types, plasma machine selection etc.

I think user levels should be pretty easy to add into the setting framework, and disable widgets when the current user level is too low.

Cheers,
Kurt

KCJ wrote:

Re: Locking settings.
I would like to add user login levels that lock out certain settings depending on the user.
 

Security is a bit topical here right now as I just stopped shipping against a fraudulent transaction today!
In a perfect world, linking the security model to the Linux account would probably be the best and most secure option.
Set some user groups for your 10 levels....

JoCo yes, some features are necessary to access sometimes (like park for loading), others need to be at your fingertips. QTPlasmac's buttons are mostly user defined. Then the user can group them.