#linuxcnc-devel | Logs for 2016-01-22

Back
[08:01:31] <JT-Shop> I'm down to this error trying to install Preemt-RT http://paste.ubuntu.com/14597579/
[08:38:52] <skunkworks> cradek, archivist, http://www.theatlantic.com/technology/archive/2016/01/pendulum-clock-john-harrison/424614/?google_editors_picks=true
[08:40:14] <JT-Shop> is there a step by step for getting LinuxCNC up and running on Preemt-RT?
[08:43:09] <skunkworks> JT-Shop, http://linuxcnc.org/docs/html/getting-started/getting-linuxcnc.html#_installing_on_debian_wheezy_with_preempt_rt_kernel
[08:43:58] <JT-Shop> opps I got off track and forgot about that
[08:44:07] <JT-Shop> no wonder it would not work lol
[08:45:02] <JT-Shop> I get so confused about all the ways to get LinuxCNC
[08:45:14] <skunkworks> heh
[08:49:22] <archivist> skunkworks, we had a bunch or harison replicas at one of the BHI open days /me had to be man standing in a corner
[08:49:30] <archivist> bunch of
[08:50:08] <archivist> also been to Greenwich and seen the originals before I became a clockmaker
[10:19:30] <jepler> JT-Shop: it looks like the linuxcnc package thinks it's been requested to build for rtai
[10:19:39] <jepler> JT-Shop: you probably needed to debian/configure uspace in an earlier step
[10:19:57] <skunkworks> well that is weird. I sent 2 messages to the list and only the second one showed up.
[10:31:36] <JT-Shop> yea, I think I totally messed up by grabbing the wrong instructions
[11:02:36] <skunkworks> and now my first message shows up...
[11:15:47] <maxcnc> hi im still on filling my setup var with a value from somwhere
[11:16:15] <maxcnc> is there a basic understanding chart how the workflow of a linuxcnc cycle is
[11:17:13] <maxcnc> i try to grep the value of motor.x.pos-cmd
[11:17:24] <maxcnc> in the early stages
[11:17:45] <maxcnc> sutch as halshow got the value displayed
[11:37:03] <JT-Shop> I wonder if the motherboard on the BP can be part of the problem? New one here today
[11:41:10] <maxcnc> i got also a change coming on monday
[11:41:33] <maxcnc> from 3.2Gh back to 900Mhz
[11:41:58] <maxcnc> maybe the 5i25 runs on that board
[11:57:28] <JT-Shop> I have a 5i25 in my plasma that has never had an sserial error
[12:03:03] <maxcnc> i got also 5+ of them but the newer ones coming do have a problem what so ever V43 +
[12:06:49] <JT-Shop> the one on the BP is an older one and it's had sserial errors since day 1, it's just too noisy in that cabinet
[12:07:19] <maxcnc> agree on the noise in plasma is realy bad
[12:13:42] <maxcnc> im lost in space on filling the values i get everything beside the G53 ofsets or Motor.pos-fb
[12:13:51] <JT-Shop> the BP is my mill
[12:13:54] <maxcnc> in interpreter
[12:14:15] <JT-Shop> G53 offset?
[12:14:24] <maxcnc> jed
[12:14:27] <maxcnc> yes
[12:14:38] <maxcnc> position
[12:14:55] <JT-Shop> I don't know of any G53 offsets only G54-59.x
[12:15:21] <maxcnc> What the Hal_show showes on axis.x.motor.pos-cmd
[12:15:59] <maxcnc> its in there as it is shown but where
[12:16:15] <JT-Shop> that's above my pay grade
[12:16:16] <maxcnc> and not knowing c++ is a hint on its own
[12:16:29] <maxcnc> _setup.unoffset_x = GET_EXTERNAL_POSITION_X() - GET_EXTERNAL_PROBE_POSITION_X();
[12:17:39] <JT-Shop> what are you trying to do?
[12:18:00] <maxcnc> filling parameters 5440-5448
[12:18:36] <maxcnc> for a plasma you got it woudt be cool to have the distance to the Bounderys
[12:18:50] <maxcnc> for instance tool probe moves along G91
[12:19:08] <maxcnc> so the coustomer starts the toolprobing somewhere
[12:19:37] <maxcnc> what G91 level you are giving a fixed may not retch the part or give ypou a boundery error
[12:20:10] <maxcnc> boundery Z is good to be set that the tourch flame do not burn your warertank
[12:20:18] <maxcnc> water
[12:20:43] <JT-Shop> homing and sensible machine limits do that
[12:21:28] <maxcnc> so workaround is to fill a analoginput in HAL with the motor.2.pos-fb
[12:21:41] <maxcnc> grep that by M66ExL0
[12:22:05] <maxcnc> fill your #<togo> =#5399
[12:22:15] <maxcnc> and move G38 that value
[12:22:26] <maxcnc> - a personel value
[12:22:32] <maxcnc> works great
[12:22:49] <cradek> after thinking more about the actual problem you are trying to solve, I think G53 G38.x probing is probably a better solution
[12:23:50] <maxcnc> it coudt also be used in other surcumstances
[12:24:24] <cradek> I think you can also get the number you want using g30.1
[12:24:35] <maxcnc> so im dione at all setup and parametring need only to find the value that is calculated somewhere that hal_show gots presented to motor.x.pos-fb
[12:25:57] <maxcnc> interp_find got this values but only as pointer and im not getting to this c++
[12:25:59] <cradek> I'm not the first one to think that: http://sourceforge.net/p/emc/feature-requests/62/
[12:26:14] <maxcnc> agree
[12:26:20] <maxcnc> and you are the master
[12:26:31] <cradek> brb
[12:27:07] <maxcnc> i need to set the probel physicle switch that near that im reatching probe hit during programm run
[12:27:48] <maxcnc> as i calculated for less waight reasens a max space between part hlder and watertank bothem acording to hypertherm flame space +5mm
[12:28:03] <maxcnc> so i got max space as 2mm
[12:29:30] <maxcnc> cradek: lets call the Call function to this GET_MASHINE_POSITION_
[12:45:31] <maxcnc> im now on the wrong place GET_... is related to Python not to rs274
[12:45:44] <maxcnc> so no need to go for that or over that
[12:49:16] <maxcnc> THIS is the Goal to get the values -> int Interp::find_current_in_system
[12:49:37] <maxcnc> but there are only pointers no values
[12:50:01] <maxcnc> so need to go back 25years to see the pointer in use
[13:22:39] <maxcnc> int Interp::find_current_in_system NO wrong wway this fiunction does nothinfg on the value after referencing neet to find a other way
[13:23:58] <maxcnc> i did check within the function p[5440] = *x; setting the parameter doe not return a value at all only the init value during rntime
[13:34:08] <maxcnc> ok i give up for today
[13:34:15] <maxcnc> will find a solution
[13:34:28] <maxcnc> as the halshow shoves the vlalues i need
[13:34:37] <maxcnc> but where are they generated
[13:34:51] <maxcnc> in python maybe as canon ald the gui is python
[13:35:43] <maxcnc> need to get info where the tcl hal_show GUI graps the values from
[13:36:15] <maxcnc> the interpr_find .cc do nothing on that
[13:36:36] <maxcnc> rs274 may be a option
[13:36:43] <maxcnc> by
[13:37:43] <jepler> cradek: oh btw our documentation says: user parameters:: numbered parameters in the range 31..5000
[13:37:48] <jepler> http://linuxcnc.org/docs/html/gcode/overview.html#_parameters
[14:44:42] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened issue #30: G53 doesn't work right with G92 and coordinate system rotation 02https://github.com/LinuxCNC/linuxcnc/issues/30
[14:45:59] <cradek> sigh
[14:46:54] <jepler> it is too coincidental
[14:46:59] <jepler> READ => g92x1
[14:47:03] <jepler> READ => g10l2p1r45
[14:47:06] <jepler> READ => (debug,#<_mx> #<_my>)
[14:47:09] <jepler> 13 N..... MESSAGE("0.292893 -0.707107")
[14:47:51] <cradek> yeah the G53 case in Interp::find_ends sure is wrong
[14:49:07] <cradek> wait, you get that without the incorrect g53 motion?
[14:49:23] <jepler> right, that's the coincidence
[14:51:00] <jepler> I get it after g0g53x0y0 too
[14:53:30] <jepler> READ => g92x1
[14:53:34] <jepler> READ => g10l2p1r45
[14:53:39] <jepler> READ => g91g0x0y0
[14:53:40] <jepler> 9 N..... COMMENT("interpreter: distance mode changed to incremental")
[14:53:43] <jepler> 10 N..... STRAIGHT_TRAVERSE(0.7071, -0.7071, 0.0000, 0.0000, 0.0000, 0.0000)
[14:53:59] <jepler> READ => g90g53g0x0y0
[14:53:59] <jepler> 11 N..... COMMENT("interpreter: distance mode changed to absolute")
[14:53:59] <jepler> 12 N..... STRAIGHT_TRAVERSE(0.7071, -0.7071, 0.0000, 0.0000, 0.0000, 0.0000)
[14:54:34] <cradek> 9,10 seem right?
[14:55:57] <cradek> wait, does the canon call have offsets in it or not?
[14:56:25] <jepler> well more to the point, in AXIS that g91 g0 x0 y0 causes machine motion
[14:56:50] <cradek> yeah that can't be right
[14:57:21] <cradek> I think line 10 should be all zeroes
[14:57:26] <cradek> well and then line 12 too
[14:57:34] <cradek> everything is terrible
[15:03:34] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #30: Instead of G0 G53 X0 Y0, you can also G91 G0 X0 Y0, which should cause motion since it's in incremental distance mode with all distances zero. It takes you to the same machine location as the G0 G53 version.... 02https://github.com/LinuxCNC/linuxcnc/issues/30#issuecomment-174039912
[16:22:43] <KGB-linuxcnc> 03Dewey Garrett 052.7 6cdc0be 06linuxcnc 10configs/sim/axis/README 10configs/sim/axis/canterp.ini 03configs/sim/axis/canterp_example.can configs/sim/canterp.ini: make runnable * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6cdc0be
[16:48:05] <jepler> I wonder which of those inifile changes were *necessary*
[16:48:45] <jepler> I ran it earlier today (possibly we were both spurred to look at it by a forum post that for some reason referred to canterp) and the only problem I saw was that it tried to load the regular old splash screen gcode and of course that didn't work.
[18:17:43] <skunkworks> zlog