#linuxcnc-devel Logs

Mar 04 2018

12:08 AM hazzy: Tom_L: I think that might be related to the problem of not updating the active codes correctly, which the state-tags branch is supposed to fix
05:44 AM rene-dev: hazzy I reported the gtk issue upstream
09:25 AM hazzy: Thank you rebe-dev! I don't know why I did not think of doing that
09:27 AM hazzy: rene-dev
09:28 AM rene-dev: :S
09:28 AM rene-dev: :D
10:11 AM rene-dev: hi andypugh
10:11 AM rene-dev: so all solved?
10:11 AM andypugh: I don’t know.
10:11 AM rene-dev: im working with norbert on that pocket issue... but we are not getting anywhere :D
10:12 AM andypugh: I have nevr had much trouble, so can’t really say
10:12 AM rene-dev: ah :D
10:12 AM andypugh: lcd is a standalone component, so he should be able to install it with halcompile
10:12 AM andypugh: (And then test)
11:33 AM andypugh: Why does the LCD work perfectly for me and not for Mike?
11:34 AM andypugh: (One possibility is that I am testing standalone in a HAL session rather than live on an actual machine as part of a complete config)
12:40 PM Tom_L: andypugh same lcd controller?
12:40 PM Tom_L: some variances act differently
12:41 PM andypugh: I thought that they were reasonably standard
12:42 PM Tom_L: most use the HD44780 controller but there are a few odd balls out there
12:42 PM Tom_L: i've got 4 4 x 20 and 2 work great but 2 give me grief
12:43 PM Tom_L: different brands
12:44 PM Tom_itx: https://dawes.wordpress.com/2010/01/05/hd44780-instruction-set/
12:44 PM Tom_L: i've got the pdf around here somewhere..
12:44 PM Tom_L: but i'm sure you've checked all that
12:46 PM Tom_L: most of the newer ones should be reasonablly compatible
12:47 PM andypugh: The HD44780 protocol is handled by Mesa. My bit talks ADM3 serial terminal protocol to the Mesa 7i73.
12:47 PM Tom_L: oh
12:47 PM Tom_L: i know they are slow devices so give it plenty of time
12:57 PM Tom_L: is the issue on a clear screen only?
01:00 PM andypugh: I have no idea what the issue is. Mine works perfectly.
01:02 PM Tom_L: makes it a little harder to diagnose
01:04 PM pcw_home: has mike posted his hal/ini files?
01:05 PM andypugh: Some of them.
01:05 PM pcw_home: if not I'll ask him and I can try and duplicate the issue
01:05 PM andypugh: One thing is that the 7i73 is in a separate HAL file, so the lcd comp runs _after_ hm2_write.
01:06 PM pcw_home: I dont see that that would make a difference
01:08 PM rene-dev: norbert also has the issue
01:09 PM rene-dev: du could not test it so far, we are still working to get the pocket numbers right
01:09 PM pcw_home: yeah and both seemed to have started at some change in master but Andy cant duplicate
01:12 PM rene-dev: is there any reason why the prolog sets new and old tool pockets and numbers, while they are also available as named parameters?
01:17 PM rene-dev: uuh, you really got creative with your modes there :D inputoutputencoderanalogwidedisplaykeycode4by8
01:21 PM andypugh: I am feeling rather discouraged, I was confident that I had made the fix by not using home-cursor any more.
01:22 PM andypugh: But I am less that convinced that mike has compiled and installed the new lcd component
01:24 PM rene-dev: I think you cant hal_compile a comp that already exists with a normal install
01:24 PM rene-dev: I remember you trying to to that on that weiler lathe, with the carousel comp
01:25 PM andypugh: Maybe Norbert can try the new version of lcd? He (apparently) has the same problem.
01:26 PM andypugh: I just tried it, it worjed fine, and copied in the new version
01:26 PM rene-dev: He can, but he needs to find all the parts and put it together... and I think currently he is very keen on the pocket numbers :D
01:26 PM rene-dev: ah, ok
01:27 PM rene-dev: currently the problem is the set_selected_pocket call in interpmodule...
04:37 PM jepler: rene-dev: I remembered another wrinkle that will affect the tooltable move
04:37 PM jepler: rene-dev: within task, there's a way to "run" or "verify" a part program.
04:37 PM rene-dev: what?
04:38 PM jepler: this "verify" is different from (older than) UI preview
04:38 PM rene-dev: how does that work?
04:38 PM jepler: it also .. mostly .. makes sure that side effects from interpreting the gcode don't actually make any difference
04:38 PM jepler: .. though I bet we have some bugs surrounding that
04:38 PM jepler: anyway, during a "verify", it'd be necessary to work on a scratch copy of the tool table, just like for preview
04:39 PM rene-dev: im working on the bugfix part now with norbert
04:39 PM jepler: "verify" is in the UI of tkemc, but not directly available in axis or other UIs
04:39 PM jepler: It's just something else to keep in mind, and of course there's not a test for it :-/
04:39 PM rene-dev: I dont see a copy of the tooltable at all
04:40 PM jepler: right, in the old/current design, "verify" would just skip communicating anything to iotask
04:40 PM jepler: but in your new design, "verify" will have to use a different method to make sure the tool table changes, loaded tool changes, etc., are reset / discarded at the end of verify
04:41 PM rene-dev: in the pull request that is on github now, the tooltable is still where it used to be. that aims to be only a little cleanup, and fix the pocket number issue. any maybe, remove the tool limit.
04:42 PM rene-dev: are you sure that actually happening? I didnt spot anything like that...
04:42 PM jepler: oh oh, this is not a criticism of the PR
04:42 PM jepler: this is related to your overall plans
04:42 PM rene-dev: yeah, I got that :D
04:42 PM jepler: I haven't actually read the PR yet :-/
04:43 PM rene-dev: I think the verify of limits and stuff is in the preview part?
04:44 PM rene-dev: I had a think about that... there are really 2 things. the plot, which is always the control point of the tool, and the actual machine position, which changes with every tlo.
04:44 PM rene-dev: limits of course only apply for the second part.
04:45 PM jepler: the preview in AXIS and other UIs has basic soft limits check when the preview is generated, but there's a second check that is in task (and probably even a third in the realtime motion controller)
04:45 PM jepler: AXIS has historically had problems with correctness where tool length offsets are involved
04:45 PM rene-dev: I came across a few bugs related to limits and TLOs, but cant point my finger at a specific one
04:46 PM rene-dev: It especially doesnt like my tool measure macro, which involves probing, and manipulating the tooltable :D
04:46 PM jepler: yes, that has been a long standing problem
04:46 PM rene-dev: yes, I think the realtime part only checks for limits as it goes along.
04:46 PM jepler: after that probe movement, all bets about Z coordinates are off
04:47 PM rene-dev: so where is the other check in task?
04:47 PM jepler: thanks for waiting until I actually found it to ask that obvious question
04:47 PM rene-dev: :D
04:48 PM jepler: so UI sends a message EMC_TASK_PLAN_RUN with the 'line' field equal to -1
04:48 PM jepler: this gets assigned to programStartLine which has some checks "programStartLine < 0"
04:49 PM jepler: next to checks like emcStatus->task.readLine < programStartLine which are also something you'll get to sweat over .. that's to implement "run from line" which is another awful part of task and very prone to regressions. and nobody's happy with how it works when it's working, anyway
04:49 PM jepler: anyway, that main check is line 567 in emctaskmain.cc for me
04:50 PM jepler: the crux of the matter is that it "discards all side effects" with that call: interp_list.clear();
04:50 PM rene-dev: yeah, I could never get that to work properly...
04:50 PM rene-dev: ah, thats probably the reason there are 2 tooltables to begin with.
04:51 PM rene-dev: I might actually have seen side effects on that. with the single tooltable design I could not get some tests to pass for some very strange reasons
04:57 PM jepler: I hope I don't seem discouraging, I just wanted to inform you about an arcane and non-obvious part of LinuxCNC (you can't even activate it from the "modern" UIs!) that will affect what you're working on
04:57 PM jepler: afk again,
04:58 PM rene-dev: what? that is not even used?
05:01 PM andypugh: Well, apparently tkemc uses it…
05:02 PM jepler: right, tklinuxcnc has it. maybe touchy? not sure. (its original design didn't have preview but many people put it in a custom tab)
05:47 PM rene-dev: why is this necessary? https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_convert.cc#L5226-L5228
05:59 PM andypugh: To make sure that the tool offsets are right if you do some machining using a tool while it is in its pocket?
05:59 PM jepler: rene-dev: I don't know. I had hoped that the commit message would be helpful but it wasn't. https://github.com/LinuxCNC/linuxcnc/commit/410af7ebc429d29a0e510da3e1a1577fb9f7620d
06:00 PM rene-dev: git blame showed me another one from mhabler, that wasnt helpful either.
06:00 PM rene-dev: its almost working now :)
06:01 PM rene-dev: andypugh I dont think you can do that... but Im sure its in there for a reason
06:03 PM rene-dev: does anyone know why stdglue goes thru a lot of trouble to set parameters that are available anyway via named parameters?
06:03 PM jepler: Is it to support programming all these codes on the same line? T1 M6 G43
06:03 PM jepler: </speculation>
06:03 PM rene-dev: it doesnt make any sense. they match up now. but when they didnt, norbert just picked whichever gave hom the right value :D
06:04 PM andypugh: jepler: I think that’s it, it is to pass the block parameters into the remap.
06:04 PM rene-dev: ah, that might be it!
08:42 PM jepler: hmph, the python digitalocan API library I picked isn't complete when it comes to manipulating DNS
09:06 PM jepler: my hobby: quoting scholarly papers out of context
09:06 PM jepler: > Current research indicates that even well-designed boxes are useless
09:06 PM jepler: https://arxiv.org/pdf/1802.02180.pdf "INTERSTELLAR COMMUNICATION. IX. MESSAGE DECONTAMINATION IS IMPOSSIBLE
09:06 PM jepler: "
09:10 PM jepler: .. the scenario might as well be calld, Roko's Monolith