Back
[11:30:42] <jepler> yuck -
https://sourceforge.net/tracker/?func=detail&atid=106744&aid=3018318&group_id=6744
[11:31:01] <jepler> from the var file alone I don't think you can tell the difference between G92 and G92.2...
[14:34:08] <micges> cradek: I've located G92 preview bug but have no idea how to solve it
[14:57:43] <cradek> jepler:
http://timeguy.com/cradek-files/emc/B.ngc
[14:58:42] <cradek> micges: yes I think the problem is you cannot tell g92 vs g92.2 from the var file
[15:06:46] <micges> I doubt that's it
[15:07:14] <micges> path is ok and preview is not
[20:14:13] <skunkworks> 32767
[20:14:17] <skunkworks> heh
[20:38:27] <alex_joni> skunkworks: ??
[20:49:51] <skunkworks> alex_joni:
http://www.youtube.com/watch?v=4nuRea6615s
[20:50:49] <skunkworks> ok - this is odd. How come when i hit the estop - the tool-prepare goes high some times?
[20:51:14] <skunkworks> tool prepare is hooked into the ladder - not to an external pin.
[20:53:45] <cradek> skunkworks: awesome!!
[20:53:48] <andypugh> I want your machine.
[20:53:55] <skunkworks> heh
[20:54:34] <skunkworks> doesn't make sense. tool-prepar is an internal emc pin
[20:54:39] <skunkworks> prepare
[20:57:27] <andypugh> In C, what is 0/0 ? I am guessing NaN?
[20:58:07] <cradek> probably - what are you doing?
[20:59:06] <andypugh> Dividing Adjacent by Hypotenuse of a triangle that might be of zero size.
[21:00:14] <andypugh> This is Visteurs waterjet kinematics, which needs to hold an angle when there is not enough information to work out the traverse direction.
[21:01:40] <cradek> his approach is bad and is not going to work
[21:01:45] <cradek> (IMO)
[21:02:33] <andypugh> Well, actually, it is my approach, and I realise it is bad, but can't think of a better one within the limitations of what a kinematics module knows.
[21:02:35] <cradek> fixing a /0 is not going to help solve the fundamental problems with the way he's chosen to try doing it
[21:03:04] <cradek> yeah, those limitations are the problem, and you just can't do this at the kins level (IMO)
[21:04:02] <andypugh> Any scope for adding a velocity vector to EmcPose?
[21:04:20] <cradek> what will you do at corners?
[21:04:35] <andypugh> Panic?
[21:04:38] <cradek> you can't have your rotaries jump from one position to another instantly when you turn a corner
[21:05:09] <alex_joni> skunkworks: it's 'flexible' not 'flexable'
[21:05:11] <cradek> this needs to be in the gcode, or if you really don't want to do that (why?), it has to be in the interpreter
[21:05:22] <alex_joni> at least I surely hope so :D
[21:05:40] <andypugh> No, but a corner requires movements in the X and Y joints too, so I am hoping that the velocity limits on those axes might catch it.
[21:06:08] <alex_joni> skunkworks: the youtube vid description
[21:08:02] <andypugh> A g-code preprocessor that is aware of nozzle length and fly height and swivel-head geometry that can track curves and spirals sounds to me like a far harder problem than solving it at the kinematics level.
[21:09:02] <andypugh> And, if I might remind you, Mr cradek, it was you who said it was an easy kinematics problem in the first place!
[21:09:14] <cradek> if so, I didn't understand the question :-)
[21:10:19] <andypugh> Anyway.. Given that any sharp corner with a head-tilt converts it to an inside or outside sweep in X and Y, I am hopeful that it might still work.
[21:12:46] <andypugh> I have a stepwise low-pass filter for the current heading, where the gain is directly proportional to how far the axes moved in the last thread, so it should ignore tiny dithers and "tend" towards a true heading.
[21:13:55] <andypugh> When I started on this I was rather assuming that the kins modules were passed rather more information than they actually are.
[21:14:36] <cradek> :-/
[21:15:24] <andypugh> Is there, actually, any possiblity of adding current velocity vector to the EmcPose structure? My assumption is that it wouldn't break anything. But I am also assuming that something upstream has the information
[21:18:24] <cradek> I don't know how hard that is, sorry
[21:22:01] <jepler> imho, velocity doesn't belong in the 'pose' structure, it's something specific. where do you really want velocity information that it's not available currently?
[21:23:13] <andypugh> Well, I guess it isn't velocity as such. What we want is current direction-of-travel
[21:23:22] <jepler> (oh, you want it as an input to kinematics?)
[21:23:59] <andypugh> Yes, we want the kinematics module to know where is it going (or where it has been) rather than just where it is now.
[21:24:43] <andypugh> The application is very similar to tool diameter offset, but not similar enough to be any help.
[21:25:41] <andypugh> I do actually think that it can be done (at least badly) by differentiating position within the kins module.
[21:26:32] <SWPLinux> I'm dubious on that :)
[21:26:34] <SWPLinux> or something
[21:30:28] <andypugh> Thinking aloud: Currently we are storing the last position, and comparing it to the new position every thread cycle. How about if we were only to store the old position if it was more than (say) .1mm from the new position, and were to only calculate the heading at that point too.
[21:31:18] <andypugh> The alternative would be a 0.1mm shift register, and a polynomial curve fit to the history. That would have to work :-)
[21:38:18] <SWPLinux> andypugh: an interesting thing that might work in HAL
[21:38:32] <SWPLinux> actually two parts
[21:38:41] <SWPLinux> err, two versions
[21:39:25] <andypugh> I am listening, I don't stop till things work...
[21:40:12] <andypugh> Viz that video I just posted to the other channel, which is something utterly overtaken by events including PCW sending me samples :-)
[21:40:40] <SWPLinux> in one, you write a module that has two functions, a "latch" function which you run before the motion controller so it can save the "before" motor pos commands
[21:40:58] <SWPLinux> and then a processing function that runs after motion, which then has the new command position
[21:41:37] <SWPLinux> I guess that's like kinematics, but it's guaranteed to run exactly once per thread execution
[21:41:39] <andypugh> Does that add anything that can't be inside a suitably elaborate kins module?
[21:42:05] <andypugh> I have been assuming that the kins modules run once per thread too.
[21:42:08] <SWPLinux> (I'm not absolutely sure that kins isn't run more than once in the motion controller)
[21:42:14] <SWPLinux> yeah, I dunno
[21:42:17] <SWPLinux> it would make sense ...
[21:42:35] <andypugh> I can see it might run forwards then reverse (or the other way round)
[21:42:57] <SWPLinux> well, technically you're right - you can have an extra HAL function in kins, so you can put "latch" there
[21:44:11] <andypugh> I guess it is easy enough to answer by having ForwardKins and InverseKins send timestamps to stdio
[21:44:40] <SWPLinux> the main issue though is that kins provides an internal mathematical transform, which may have additional corrections applied afterwards (such as screw mapping or backlash)
[21:44:50] <CIA-4> EMC: 03cradek 07v2.4_branch * r5ac91f2d7835 10/src/emc/ (5 files in 4 dirs): remove SPLINE canon calls and use NURBS instead
[21:45:20] <SWPLinux> it technically should be part of the motion controller code, but it's a separately linked module to make it easier to swap around in the configs
[21:45:44] <SWPLinux> (otherwise you need a bunch of separate motion controllers, depending on the kins)
[21:46:24] <andypugh> SWPLinux: Let us see how we get on with the kludge, last message from the Estonian was that it was actually working...
[21:47:00] <SWPLinux> oh, well in that case carry on ;)
[22:03:34] <CIA-4> EMC: 03jepler 07v2.4_branch * r5f64a07f5997 10/src/emc/task/emccanon.cc: avoid division by zero
[22:03:35] <CIA-4> EMC: 03jepler 07v2.4_branch * r7ed7a64c8446 10/src/emc/rs274ngc/ (interp_internal.cc interp_internal.hh interp_read.cc): Make it possible to check whether Q is specified
[22:03:36] <CIA-4> EMC: 03jepler 07v2.4_branch * r1897c1992869 10/src/emc/rs274ngc/interp_convert.cc: G5 without P, Q is an error; diagnose it
[22:03:37] <CIA-4> EMC: 03jepler 07v2.4_branch * r5ee9249f3bb7 10/src/emc/ (3 files in 3 dirs): provide a function to calculate nurbs tangent
[22:03:38] <CIA-4> EMC: 03jepler 07v2.4_branch * r8cdc465a037c 10/src/emc/rs274ngc/gcodemodule.cc: remove outdated comments
[22:03:39] <CIA-4> EMC: 03jepler 07v2.4_branch * rd27fb2504436 10/src/emc/task/emccanon.cc: fix G1 followed by G5.x
[22:03:39] <CIA-4> EMC: 03jepler 07v2.4_branch * r677e20ce008f 10/src/hal/utils/comp.g: don't emit MODULE_LICENSE repeatedly
[22:03:54] <CIA-4> EMC: 03swpadnos 07master * r19977b1ba2ba 10/src/hal/components/thc.comp: mode change (to 644)
[22:29:44] <skunkworks_> alex_joni: thanks! :) you know me and spelling
[22:31:31] <skunkworks_> hmm. probably won't be able to trouble shoot that problem until after the fest
[22:33:57] <jthornton> what does changing the mode of the comp file do? Just curious...
[22:34:52] <SWPLinux> jthornton: makes it the same as all the others in the directory - you can't execute source
[22:35:19] <SWPLinux> I imagine you copied it to a vfat-formatted USB flash drive at some point in its life
[22:35:51] <jthornton> I can image that it was copied all over the place LOL while working on it
[22:36:54] <skunkworks_> I suppose a kudge would be to make the tool-prepared go true during a estop..
[22:38:24] <skunkworks_> I must be doing something wrong.
[22:38:26] <skunkworks_> ;)
[22:40:58] <jthornton> speaking of tool changers is there a way to gracefully abort a tool change?
[22:42:02] <cradek> I don't think so
[22:42:05] <skunkworks_> heh
[22:43:00] <skunkworks_> I was manually setting tool-prepared to true - to get out of the tool change
[22:43:57] <jthornton> I guess I could try that and bailing from the current program if one is running
[22:46:19] <jthornton> * jthornton wanders out to the shop to make a network cable for the Zotac
[23:12:52] <SWPLinux> there was a fair amount of thought that went into the toolchange logic for the Mazak
[23:13:07] <SWPLinux> for things like recovering from a partially completed change, etc
[23:13:12] <SWPLinux> (IIRC)
[23:15:52] <jthornton> I'll take a gander at that too
[23:19:08] <skunkworks_> I wouldn't think noise would make an internal pin of emc to trip.
[23:42:27] <cradek> http://timeguy.com/cradek-files/emc/0002-Save-state-of-G92-correctly-across-restarts.patch