Loading nozzle speed and unloading nozzle speed behaves different

[lilltroll77]

I think the speed needs a fix for load unload nozzle under Machine setup.

If
l_n = location for position n
v_n = speed for ???
v_1 is during loading between l_1 -> l_2 ?
but during unloading l_2 -> l_1 gets speed v_2 !?

That need to be shifted to v_1, and so on for v_3...v_4, otherwise loading and unloading behaves different.

Maybe it instead should be 3 or 5 Speed textboxes located between the location boxes, since the speed is between 2 locations.

[vonnieda]

I like the idea of making it clear that the speed is to be used between specific locations.

[lilltroll77]

@vonnieda
I started to play with the java code.
I'm not new to GUI programming, eclipse or git - but I'm completely new to java and swing.
What about this basic idea (testing different label-positions) - or should I change the Formlayout to a non-grid variant. In such case, any proposals which one you prefer to make the graphics scale correctly.

I have also added ToolTipText.

[vonnieda]

I think the first variant with the label to the left looks good. I don't think there is any reason to change the layout. If you are new to Swing development in OpenPnP, make sure you are using WindowBuilder: https://eclipse.org/windowbuilder/ This is how all of the UIs in OpenPnP are created and it is much easier than trying to edit layout constraints by hand. Jason

…

On Thu, Jun 29, 2017 at 4:49 AM Mikael ***@***.***> wrote: I started to play with the java code. I'm not new to GUI programming, eclipse or git - but I'm completely new to java and swing. What about this basic idea (testing different label-positions) - or should I change the Formlayout to a non-grid variant. In such case, any proposals which one you prefer to make the graphics scale correctly. [image: image] <https://user-images.githubusercontent.com/493682/27681663-4b3b2968-5cc0-11e7-8e73-df3c86b2bea5.png> I have also added ToolTipText. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#584 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABIKc8SY1sxwcXkSI-u8uXNS-o7-yE4uks5sI3MagaJpZM4N9k9R> .

[lilltroll77]

I suspected that something like WindowBuilder was involved.
I will check that out and try to fix the rest of the code as well.

[lilltroll77]

I have working code now, based on WindowBuilder including the speed calculations.
It loads and unloads the nozzle without spitting them out on the table due to incorrect speeds.

But I do not have a clue how to make the code backward compatible with the (old) machine.xml

With my current naming it looks like this

<nozzle-tip class="org.openpnp.machine.reference.ReferenceNozzleTip" id="e092921a-2eef-449b-b340-aa3f40d8d791" name="507" allow-incompatible-packages="false">
                        <compatible-package-ids class="java.util.HashSet"/>
                        <changer-start-location units="Millimeters" x="149.4" y="77.3" z="-13.8" rotation="0.0"/>
                        <changer-start-to-mid-speed>0.01</changer-start-to-mid-speed>
                        <changer-mid-location units="Millimeters" x="149.4" y="77.0" z="-17.6" rotation="0.0"/>
                        <changer-mid-to-mid-2-speed>0.025</changer-mid-to-mid-2-speed>
                        <changer-mid-location-2 units="Millimeters" x="149.4" y="25.0" z="-16.5" rotation="0.0"/>
                        <changer-mid-2-to-end-speed>0.04</changer-mid-2-to-end-speed>
                        <changer-end-location units="Millimeters" x="149.4" y="17.0" z="-16.5" rotation="0.0"/>
                        <calibration angle-increment="15.0" enabled="false">
                           <pipeline>
                     

(I haven't read the google naming of variables enough yet.)

But how to handle the old way with 4 speed settings in machine.xml? Can it be controlled with compatibility package settings?

[vonnieda]

@lilltroll77 First, thank you for running with this and for thinking about the issue of backwards compatibility!

The way I usually handle this kind of thing is to add the new variables, as you've done, and then add a method like this:

@Commit
public void commit() {
    // copy old variables into new and set old ones to null or 0
}

The commit method is called by the configuration serializer after it loads the config. So what will happen is that the first time a user with an old config loads their config with this new code, it will copy the variables into the new spots and zero out the old ones. Finally, I'll add a // TODO to remove the old stuff in 6 months or so.

You can also change the old variables from double to Double (primitive to object) and set them to null. This will remove them entirely from the old config once it's saved.

As for the mapping from old to new, I'll leave that to you to figure out. I think anything reasonable will be fine and we'll just let users know they should check their settings after installing the update.

[lilltroll77]

Ok, I did changed from double to Double and added a check and convert for old variables to new ones.
Now it looks like this. It seems to work when I add old variables to my XML.
lilltroll77@f09c5c2

[vonnieda]

@lilltroll77 Looks great! Only thing I see missing is failing to null changerStartSpeed, changerMidSpeed and changerStartSpeed2 after copying them into their new home.

[lilltroll77]

Things went crazy here 2 days ago when I tried to handle git within eclipse and change the repo from openpnp to my fork. All changed files became empty of some reason. I think everything is in sync now on my side. I have made a pull request.

[vonnieda]

Fixed in #596