[LinuxCNC/linuxcnc PR#528] 2.7 pocket fix

#1 – Lcvette 于 2018-11-16

This is awesome! Rene, hazzy and I are excited to use your table in the new gui project! You should stop by the qtpyvcp irc and check us out!

#2 – rene-dev 于 2018-11-16

this is not the new tooltable, thats next, after another cleanup… this only fixes interp and remaps getting the wrong pocket number, and to have a set of tests that represent the expected behavior.

#3 – rene-dev 于 2018-11-17

looks like the remap is still broken, there is no test for them. I will add a workaround for that. but the interp variables are ok, just use them in the m6 remap.

#4 – rene-dev 于 2018-11-18

I got another bug reported: on prepare, the pocket numbers are delayed by one in the remap. No idea why the tests didnt catch that…

#5 – Lcvette 于 2018-11-18

Ah gotcha! well I am glad to see you are back at it again! Hazzy and Turboos and myself are VERY excited bever the less for the new tool teable when you have time for it and are eager to be able to implement it into the new gui for the ATC functionality which we are struggling with due to the old tool table. Between Your Efforts on the new tool table and Hazzy’s and Turboss’s efforts on the QtPyVCP, LCNC is on its way to a really awesome place! so at least from me and I know Hazzy and Turboss, a VERY BIG THANK YOU!!!!

#6 – TurBoss 于 2019-03-13

@rene-dev : hi,
I just noticed that pocketprepped return the index of stat.tooltable wich is a list that skips empty slots

does this make any sense

#7 – KurtJacobson 于 2019-03-13

@TurBoss I think 4e86bab fixed that problem by adding pocketno to the tool table struct so we don’t have to rely on the index anymore, which is only valid if there are no “gaps” in the tooltable.

#8 – plmicia 于 2019-04-01

Hi Guys,
I am not sure but I think I found where pocket no. is linked with Remap.
Only one line to modify in ‘interp_find.cc’ (insrc/emc/rs274ngc):
“
int Interp::findtoolpocket(setup_pointer settings, int toolno, int *pocket)
{
if(!settings->random_toolchanger && toolno == 0) {
*pocket = 0;
return INTERP_OK;
}
*pocket = -1;
for(int i=0; iPOCKETSMAX; i++) {
if(settings->tool_table[i].toolno == toolno)
//it was: *pocket = i;
//it should be:
*pocket = settings->tool_table[i].pocketno;
}
CHKS((*pocket == -1), (_("Requested tool %d not found in the tool table")), toolno);
return INTERP_OK;
}
“
Now when I issue Mx Tx command it returns correct pocket values in both iocontrol and remap (at least for me). I have not done any intensive tests so I am not sure if this change has any side effects.
My compile conditions:
– Random_toolchanger = 0
– Commit like in #528 4e86bab

I will be appriciate if somebody could doublecheck that and commit if it is ok.
@gmoccapy @rene-dev @SebKuzminsky @andypugh @KurtJacobson @lcvette

#9 – rene-dev 于 2019-04-08

Dont do that, it has very bad side effects. I think I have a fix for it.

#10 – Lcvette 于 2019-04-09

> this is not the new tooltable, thats next, after another cleanup… this only fixes interp and remaps getting the wrong pocket number, and to have a set of tests that represent the expected behavior.

@rene-dev

Turboss and I are at the last obstacle of the atc portion of our gui project (for now) and it is dealing with the Interp and Turboss has some questions on it and we were hoping perhaps you could enlighten us so we could complete this leg of the project.

Turboss’s question: “rene-dev: how can we use the bundled boost python interpreter from within systems python?

I would like to read parameters”

we are in the QtPyVCP IRQ on matrix where we collaborate, if you have a spare moment and could maybe nudge us in the right direction we would be grateful!

Thanks Rene!

Chris

#11 – rene-dev 于 2019-04-10

It should all work now, even remaps now get the correct pocket number. the interp variables are not correct if you remap T. This is expected, as they are set by the internal T call, which is not executed if you have a remap. They are however updated by the sync, therefore they are delayed by one cycle. This has nothing to do with this fix, its just how remaps work. Im still looking for a nice way of fixing this.

#12 – gmoccapy 于 2019-04-13

As you mentioned the T-remap does not work as it should, but remaping only M6 all is good.
I checked with all my possible configs and all do work as expected, even if you change tool pocket relation within a gui. I tested with non random and random tool changer!

Very good job rene-dev, thank you.

Norbert

#13 – mydani 于 2019-05-09

Hi Rene,

I think in interpconvert.cc in line 5256 is an issue, the variable pocket (little misleading) contains the tool table index, but not the actual pocket. Instead, the findtoolpocket(…) should be used to find the real pocket for the given tool and this should be assigned to settings->selectedpocket.

Can you confirm?

Regards,
Daniel

#14 – shulter 于 2019-06-26

T0M6 and M61Q0 are broken: pocket from the previous tool is kept, not updated to pocket 0.

#15 – rene-dev 于 2020-05-06

This is now in 2.8 and in master.