qtvcp issues

More
06 Jan 2019 20:37 - 06 Jan 2019 20:37 #123633 by auto-mation-assist
Replied by auto-mation-assist on topic qtvcp issues
I agree and have done some further checking and found that something has caused the handler to have a error in it somewhere that is causing the gui not to open up fully. It may not be getting a status message.

This problem not causing a error message so it may take some time to isolate the problem with 2600 lines of code to go through. Latest backup up works but I do not wish to loose the latest changes.
Last edit: 06 Jan 2019 20:37 by auto-mation-assist.

Please Log in or Create an account to join the conversation.

More
07 Jan 2019 02:58 - 07 Jan 2019 02:59 #123665 by auto-mation-assist
Replied by auto-mation-assist on topic qtvcp issues
I took a break from my trouble shooting to write up a little bit of info on how I produce the jogging increment lists with the present code.

The attached file has that write-up and also the actual code being used by me at this time. I wrote this code to generate three python lists that that can handle up to 20 increment steps per list since there 20 buttons for each list, linear inch increment jogging, linear mm increment jogging, and angular increment jogging.

The lists generated are used to label each button and also used to set the buttons true string value of each button. The lists generate a value of -1 for each button not being used and that value can be used as a option to hide buttons instead of labelling them or just label those with blank. I rather have a blank button than an empty space so I know that there are things available for other potential uses.

File: generate_incr_lists.txt is attached for review
Attachments:
Last edit: 07 Jan 2019 02:59 by auto-mation-assist.

Please Log in or Create an account to join the conversation.

More
07 Jan 2019 03:43 #123668 by cmorley
Replied by cmorley on topic qtvcp issues
I would suggest to use built in methods/libraries as much as possible.
Then as linuxcnc changes or bugs are fixed they automatically get fixed.
eg checking for machine units. you do it in your code, but qtvcp supplies a library function for it that is more robust then yours is. (you check the TRAJ heading but it can be missing so should check the AXIS_0 heading as a fall back)

I like the idea of separate increment entries in the INI.

I think another way to do this, would be to use jog increments action buttons.
Then parse your INI settings and update the action buttons.

This then would take care of all unit conversions, machine units base check etc.

The only thing I see that is missing is action buttons don't allow anything but degrees for angular axes currently.

my 2 cents.

Chris M

Please Log in or Create an account to join the conversation.

More
07 Jan 2019 07:55 - 07 Jan 2019 08:04 #123676 by newbynobi
Replied by newbynobi on topic qtvcp issues
@auto-mation-assist

IMHO is is not the good way to do that the way you are proposing. Why not use dictionaries to make the needed widgets on the fly?
That is the way I do that with gmoccapy_3.0 (actual development)

First we get all jog increments from INI file
self.jog_increments = self.get_ini_info.get_increments()

in get_ini_ifo we have
    def get_increments(self):
        jog_increments = []
        increments = self.inifile.find("DISPLAY", "INCREMENTS")
        if increments:
            if "," in increments:
                for i in increments.split(","):
                    jog_increments.append(i.strip())
            else:
                jog_increments = increments.split()
            jog_increments.insert(0, 0)
        else:
            jog_increments = [0, "1.000", "0.100", "0.010", "0.001"]
            print("**** GMOCCAPY GETINIINFO **** \nNo default jog increments entry found in [DISPLAY] of INI file\nUsing default values")
        return jog_increments

in the GUI code we can build them with:
    def _make_jog_increments(self):
        print("**** GMOCCAPY INFO ****")
        print("**** Entering make jog increments")
        # Now we will build the option buttons to select the Jog-rates
        # We do this dynamically, because users are able to set them in INI File
        # because of space on the screen only 10 items are allowed
        # jogging increments

        self.incr_rbt_dic = {}

        # We get the increments from INI File
        if len(self.jog_increments) > 10:
            print(_("**** GMOCCAPY build_GUI INFO ****"))
            print(_("**** To many increments given in INI File for this screen ****"))
            print(_("**** Only the first 10 will be reachable through this screen ****"))
            # we shorten the increment list to 10 (first is default = 0)
            self.jog_increments = self.jog_increments[0:11]

        # The first radio button is created to get a radio button group
        # The group is called according the name off  the first button
        # We use the pressed signal, not the toggled, otherwise two signals will be emitted
        # One from the released button and one from the pressed button
        # we make a list of the buttons to later add the hardware pins to them
        label = _("Continuous")
        rbt = gtk.RadioButton(None, label)
        rbt.set_property("name","rbt_0")
        rbt.connect("pressed", self._jog_increment_changed, rbt.name)
        self.widgets.vbtb_jog_incr.pack_start(rbt, True, True, 0)
        rbt.set_property("draw_indicator", False)
        rbt.show()
        rbt.modify_bg(gtk.STATE_ACTIVE, gtk.gdk.color_parse("#FFFF00"))
        self.incr_rbt_dic[rbt.name] = rbt
        # the rest of the buttons are now added to the group
        # self.no_increments is set while setting the hal pins with self._check_len_increments
        for item in range(1, len(self.jog_increments)):
            name = "rbt_{0}".format(item)
            rbt = gtk.RadioButton(self.incr_rbt_dic["rbt_0"], self.jog_increments[item])
            rbt.set_property("name",name)
            rbt.connect("pressed", self._jog_increment_changed, rbt.name)
            self.widgets.vbtb_jog_incr.pack_start(rbt, True, True, 0)
            rbt.set_property("draw_indicator", False)
            rbt.show()
            rbt.modify_bg(gtk.STATE_ACTIVE, gtk.gdk.color_parse("#FFFF00"))
            self.incr_rbt_dic[rbt.name] = rbt
        self.incr_rbt_dic["rbt_0"].set_active(True)

in the following code, you can reach all btn actions with:
self.incr_rbt_dic[<<name of the button>>]

this way we do not force the user to change their config.

If you have more place that user increments, just fill that space with empty labels.

According to the units changes I would suggest to use the hal status message, I do this in gmoccapy with the following
    def on_hal_status_metric_mode_changed(self, widget, metric_units):
        # set gremlin_units
        self.widgets.gremlin.set_property("metric_units", metric_units)

        widgetlist = ["spc_lin_jog_vel"]

        # self.stat.linear_units will return 1.0 for metric and 1/25,4 for imperial
        # display units not equal machine units
        if metric_units != int(self.stat.linear_units):
            # machine units = metric
            if self.stat.linear_units == _MM:
                self.faktor = (1.0 / 25.4)
            # machine units = imperial
            else:
                self.faktor = 25.4
            self.turtle_jog = self.turtle_jog * self.faktor
            self.rabbit_jog = self.rabbit_jog * self.faktor
            self._update_slider( widgetlist )

        else:
            # display units equal machine units would be factor = 1,
            # but if factor not equal 1.0 than we have to reconvert from previous first
            self.turtle_jog = self.turtle_jog / self.faktor
            self.rabbit_jog = self.rabbit_jog / self.faktor
            if self.faktor != 1.0:
                self.faktor = 1 / self.faktor
                self._update_slider(widgetlist)
                self.faktor = 1.0
                self._update_slider(widgetlist)

        if metric_units:
            self.widgets.spc_lin_jog_vel.set_digits(0)
            self.widgets.spc_lin_jog_vel.set_property("unit", _("mm/min"))
        else:
            self.widgets.spc_lin_jog_vel.set_digits(2)
            self.widgets.spc_lin_jog_vel.set_property("unit", _("inch/min"))

Norbert
Last edit: 07 Jan 2019 08:04 by newbynobi.

Please Log in or Create an account to join the conversation.

More
07 Jan 2019 09:24 #123678 by auto-mation-assist
Replied by auto-mation-assist on topic qtvcp issues
Norbert,

Thank you for your comments. I'm somewhat familiar with your code and refer to it on a regular basis when thinking about potential methods to solve an issue. For now I will stick with the way I have it since it is working very well and has proven to be very reliable. The lists, which are really arrays provide a good way to share control information between various functions and are items which I have used for many years including control systems for government use.

The use of separate list for inch and mm has also proved to be very beneficial and is something that can easily be implemented especially in new construction.

Please Log in or Create an account to join the conversation.

More
07 Jan 2019 09:31 - 07 Jan 2019 09:32 #123679 by auto-mation-assist
Replied by auto-mation-assist on topic qtvcp issues
I have isolated my problem that would not allow access to nearly all my buttons on the 1xmill gui. It appears that when I was making some up dates with a "find and replace" action it went a little further than I had expected.

It had charged this: '.setEnabled(True)'
to this: '.setEnabled(enabled)'

All is well now.
Last edit: 07 Jan 2019 09:32 by auto-mation-assist.

Please Log in or Create an account to join the conversation.

More
07 Jan 2019 11:56 #123697 by newbynobi
Replied by newbynobi on topic qtvcp issues
If you like, just take a look at my gmoccapy_3_0 branch
gmoccapy_3_0

It is a working version with the possibility up to 9 axis and for trivial and non trivial kinematics.
So also a lathe with C and W axis is possible, all changeable widgets are created dynamically.
It just miss the possibility of a non trivial kinematics with more than 7 joints, but that will be done in short time.

I will publisch this very soon, so I can get than to the new GUI based on pyQT

Norbert

Please Log in or Create an account to join the conversation.

More
07 Jan 2019 20:49 #123721 by cmorley
Replied by cmorley on topic qtvcp issues

Norbert,

Thank you for your comments. I'm somewhat familiar with your code and refer to it on a regular basis when thinking about potential methods to solve an issue. For now I will stick with the way I have it since it is working very well and has proven to be very reliable. The lists, which are really arrays provide a good way to share control information between various functions and are items which I have used for many years including control systems for government use.

The use of separate list for inch and mm has also proved to be very beneficial and is something that can easily be implemented especially in new construction.


In your function get_info(), you duplicate functions already available in qtvcp (in the Istat library)
While I see you check for machine unit base, i don;t see where you check for machine unit mode (G21/20).
Nor do I see any conversions. Do you do all that when actually jogging?

It seems to me you are creating your own way of jogging, without using any of Qtvcp's idioms.
This creates some issues.
anyone who decides to modify your screen with builtin widgets, say a status label for jog increment, will fail.
the amount of people who can debug and fix problems become less and less.
any changes to linuxcnc down the line that creates problems must be fixed in many places, rather then just the base library.

These are problems that I hope we can work together to minimize.
This is not to say that I think people shouldn't do things differently then standard widgets allow, it means we should work hard to incorporate relevant idioms into new widgets/concepts.

Eg use action button, but use code to reassign the increments from an INI file. As far as I can tell this changes nothing function wise in the screen but allows normal widgets to work properly plus the actual jogging code is common.

The same for Norberts suggestion of building wIdgets on the fly - build them with action widgets on the fly.

If one builds completely new widgets then it makes sense (though is a little more work) to use the available libraries/code examples to support the rest of the widget system, so things like jogging with widgets is consistent and error free. Noone wants to crash a machine because two buttons jog differently.

For my part I try to comment the code reasonably and I have added 5 subjects of documentation.
If anyone lets me know of specific questions i will try to answer and document them.

As you can tell i am passionate about making easy to maintain screens/code - ask me why :)
Chris M

Please Log in or Create an account to join the conversation.

More
07 Jan 2019 21:35 #123726 by newbynobi
Replied by newbynobi on topic qtvcp issues
Attantion!

My code example as well as gmoccapy 3.0 is gtk based!
So that is not the qtvcp way!

I do convert all metric imperial stuff on the fly as i do listen to hal status metric or prior to the combi_dro signals!

I create the widgets on the fly, as that way only the needed widgets need to be loaded and that lead to performance increase.

As what widgets to use, is up to the command, bin glade theire are no special jog button.

Wait a few weeks and i start "MINOS" a new qt based GUI with at least the features of gmoccapy. I just need to finish gmoccapy 3.0 and i am on the last steps!

Norbert

Please Log in or Create an account to join the conversation.

More
07 Jan 2019 22:25 #123729 by cmorley
Replied by cmorley on topic qtvcp issues
I have a big update to hal_glib that i want to put in master but have been holding off. but maybe i should add it so you can possibly use some of the code.

anyways that should be in a separate post - i'lll try to keep it to X1mill related stuff here :)

Chris M

Please Log in or Create an account to join the conversation.

Moderators: cmorley
Time to create page: 0.142 seconds
Powered by Kunena Forum