#linuxcnc-devel | Logs for 2012-04-27

Back
[00:02:51] <alex_joni> which ones do you mean?
[00:04:04] <micges> 10.04 rtai kernel package
[00:04:33] <micges> one used to make linuxcnc.iso
[00:05:13] <alex_joni> not separately, but they are on the iso
[00:05:37] <alex_joni> I wonder if anyone will make an adeos patch for 3.x
[00:06:04] <micges> it's overcomplex
[00:08:15] <alex_joni> well, off to bed for me
[00:08:18] <alex_joni> gnight all
[00:08:32] <mozmck> Hi micges!
[00:08:56] <micges> nite alex
[00:09:28] <micges> hi mozmck, any news about new rt kernel?
[00:09:42] <micges> or you are out of buisness this time?
[00:10:33] <mozmck> I haven't really had much time to look at it. If someone else has time that would be great. Also there is no adeos/rtai patch for 3.2.
[00:11:44] <mozmck> So cradek worked on updating the latest patch available, and I really need to see if it will work.
[00:12:01] <mozmck> I don't know if cradek has had time to try it.
[00:12:23] <micges> I see
[00:21:07] -!- mikegg has quit [Ping timeout: 276 seconds]
[00:21:16] -!- Loetmichel has quit [Ping timeout: 250 seconds]
[00:28:00] -!- Nick001 has quit [Ping timeout: 260 seconds]
[00:28:20] -!- micges has quit [Quit: Leaving]
[00:30:23] -!- asdfasd has quit [Ping timeout: 265 seconds]
[00:46:02] -!- andypugh has quit [Quit: andypugh]
[00:48:31] -!- Nick001 has quit [Ping timeout: 265 seconds]
[00:51:42] -!- stevegt_1 has quit [Ping timeout: 245 seconds]
[01:02:07] -!- skunkworks__ has quit [Ping timeout: 244 seconds]
[01:02:46] -!- Valen has quit [Quit: Leaving.]
[01:04:08] -!- skunkworks__ [skunkworks__!~chatzilla@str-bb-cable-south-3-102.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[01:15:07] -!- sumpfralle has quit [Quit: Leaving.]
[02:31:59] -!- Thetawaves has quit [Quit: Leaving]
[02:34:05] -!- dimas_ has quit [Ping timeout: 244 seconds]
[02:39:19] -!- demacus has quit [Ping timeout: 245 seconds]
[03:10:22] -!- toastydeath has quit [Ping timeout: 272 seconds]
[03:11:26] <KimK> It looks like 12.04/Precise has been released, along with all its accompanying flavors, according to http://distrowatch.com/ I'm leeching torrents now.
[03:44:10] -!- cevad has quit [Ping timeout: 260 seconds]
[03:52:55] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[04:07:39] -!- Nick001 has quit [Ping timeout: 265 seconds]
[04:20:49] -!- psha [psha!~psha@188.65.232.26] has joined #linuxcnc-devel
[04:36:00] -!- Valen has quit [Quit: Leaving.]
[05:02:45] -!- Fox_Muldr has quit [Ping timeout: 265 seconds]
[05:10:41] -!- toast2 has quit [Ping timeout: 272 seconds]
[05:20:34] cylly2 is now known as Loetmichel
[05:37:19] -!- iwoj has quit [Read error: Connection reset by peer]
[05:37:44] -!- iwoj has quit [Client Quit]
[05:39:17] -!- Tecan has quit [Quit: live long and phosphor]
[05:43:45] -!- n2diy_ has quit [Ping timeout: 260 seconds]
[05:47:58] <cmorley> mhaberier: If I understand you correctly - what you are saying is if we want to advance linuxcnc's capabilities much further without hacks, in your opinion, we need to plug in information at the last possible moment. This is because if the information is not bound early it simplifies making changes.
[05:49:03] <cmorley> so the advantage is easier and move advanced features in the future but alot of changes and instability possible in the short time.
[05:49:23] <cmorley> any other advatages/disadvantages?
[06:21:15] -!- iwoj has quit [Quit: Textual IRC Client: http://www.textualapp.com/]
[06:24:38] -!- n2diy__ has quit [Ping timeout: 240 seconds]
[06:31:15] e-ndy|afk is now known as e-ndy
[06:34:33] -!- psha has quit [Quit: Lost terminal]
[07:10:01] -!- Nick001 has quit [Ping timeout: 256 seconds]
[07:14:00] -!- mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[07:21:40] <mhaberler> cmorley: on the issue at hand - how do you cope with operations during pause - you're spot on
[07:21:52] <mhaberler> you can either fudge it at the motion level trying to not rock the boat for the rest of linuxcnc with some limited options
[07:22:25] <mhaberler> I suggested at looking at the larger picture and revisit where decision are commited
[07:22:51] <mhaberler> wrt to the offsest early/late binding discussion and stability:
[07:23:39] <mhaberler> I wouldnt go about it by changing the handling of existing offsets, because the concept needs to be validated first
[07:25:31] <mhaberler> to do so, I would introduce a new offset, which is zero by default, and handled along the new rules, completely ignoring the existing ones with the only difference that it applied after task has issued the move, and a provision to change it during pause or feedhold
[07:25:59] <mhaberler> that is a fairly isolated change which should show pretty quick if there's a fundamental flaw in the approach
[07:26:26] <alex_joni> mhaberler: good morning
[07:26:34] <mhaberler> bon giorno!
[07:26:41] <alex_joni> sleep well?
[07:26:45] <mhaberler> like a log
[07:27:04] <mhaberler> cat insisted on attention :-/
[07:28:08] <alex_joni> heh, so you're ready to go again :D
[07:28:45] <mhaberler> not before coffee #3
[07:28:54] <alex_joni> hehe, kidding
[07:29:35] <alex_joni> mhaberler: I am not concearned you'll not be able to make it work (either by the cautious approach as you just said, or completely moving offsets)
[07:31:06] <alex_joni> as I was saying (and probably it didn't come clearly across) I am worried that lateron you'll see that some other redesign is also needed, and your work needs to be redone
[07:37:39] <mhaberler> I'm unsure what you mean by 'redo'. As I said, I'm all for impact minimization, but from that it doesnt follow linuxcnc has reached entropy in terms of design shakeout - some things in are superb, and some are really bad. I would suggest the desire for stability should not preclude the discussion and eventual implementation of changes where this is warranted
[07:41:16] <mhaberler> It also doesnt necessarily follow that a change implies greater complexity. An example: if one were to dump NML completely, and switch to an RPC scheme based on google protocol buffers, then you wouldnt only get automatic & complete NML bindings for any language under the sun, you enable the replacement of things like emcsh and emcrsh by simple python scripts which would be a simplification IMV
[07:41:45] <mhaberler> note that I did NOT propose to do that. It's called a thought experiment;)
[07:46:35] <mhaberler> returning to the issue, on the math level, the question is: is application of offsets commutative? I think this was what cradek was referring to - if I understand him correctly, an offset is; a rotation is not. very important fundamental assumption which should be spelled out.
[07:47:48] <mhaberler> really what the rules of 'offset algebra' are.
[07:48:36] <mhaberler> if we can clarify that point, this would take out the guesswork of discussions. See my point or too fuzzy?
[07:51:21] -!- factor has quit [Read error: Connection reset by peer]
[08:02:40] -!- rob_h [rob_h!~rob_h@5ace70d6.bb.sky.com] has joined #linuxcnc-devel
[08:05:28] -!- the-jub has quit [Remote host closed the connection]
[08:05:37] <alex_joni> yeah, kinda.. just a bit busy atm ;)
[08:09:17] <mhaberler> ok, you're discharged (but not from background processing ;)
[08:25:46] <KimK> mhaberler: Thanks for your work on jog while paused. Can you stand yet another comment, or have you had enough for awhile, lol?
[08:26:29] <mhaberler> this is a very good question.. go ahead anyway!
[08:28:38] <KimK> Ha, OK, thanks. I know you are just working this as an example of what could be done. Would be very hard to change the nature of the jogging to "exactly retrace your steps" instead of "take the shortest path? And to make "recover" act only like feedhold, except jogging becomes enabled (no automatic moves)?
[08:28:54] <KimK> s/Would be/Would it be/
[08:29:24] <KimK> s/make "recover"/make "retract"/
[08:29:34] <mhaberler> that was the core of Ken's idea, and it is doable completely within a HAL user component like gladevcp
[08:30:30] <mhaberler> you probably mean something like the fanuc record and replay stuff I posted recently. Yes, that's covered but not done-
[08:31:03] <KimK> OK, thanks. Yes, the example that you showed in your video works pretty well for "common" situations in a vertical mill, but not so well in a lathe, or in a vertical mill with "unusual situations".
[08:32:42] <mhaberler> the idea is that on pause you sort of hand off control to the userland halcomp, and it decides what to do. Since motion can pass on a bit of information - the type of move (line, circle, tap) it could be a bit clever what to do depending on type of interrupted move
[08:33:02] <mhaberler> not totally clever, a but clever ;)
[08:33:08] <mhaberler> but/bit
[08:34:36] <KimK> I am not familiar with how Fanuc handles it, but yes, some kind of record and playback seems needed. I think that Dynapath/Autocon controls go into feedhold (sort of) when you press "retract" and you then get three jogs (like a genie gives three wishes?). Then when you press "recover", it retraces your steps. This allows handling of more complex situations like back-trepanning in a lathe.
[08:36:01] <KimK> And when back-trepanning, your first jog will be -Z (deeper into the part) to free the tool. It's not always +Z to "escape".
[08:36:56] <KimK> Sorry if I'm the 99th guy to mention this.
[08:37:04] <mhaberler> fine, so the sign of the offset applied is negative for z
[08:37:37] <mhaberler> there is no 'retract' command per se, there is an offset input into motion which is applied if it changes
[08:37:56] <mhaberler> so it will execute whatever the driving hal module tells it to do
[08:39:37] <KimK> OK, great. I just wanted to be sure that this situation was covered. It sounds like you plan to cover it thoroughly. Thanks for all your hard work, I'll look forward to seeing the finished product.
[08:39:52] <mhaberler> you probably refer to #2 in http://www.mail-archive.com/emc-developers@lists.sourceforge.net/msg06205.html
[08:41:08] <mhaberler> #1 .. #4 can be done with this approach, #5 cannot
[08:42:11] <mhaberler> as cannot a change of offsets like possibly implied in a toolchange, which was the start of the shitstorm ;)
[08:42:36] <mhaberler> ok, I retract the qualification of the discussion, this wasnt fair.
[08:42:57] <KimK> The #5 would be very handy in wire EDM machines.
[08:43:22] <mhaberler> that was the 'applicator' idea I referred to yesterday
[08:43:32] <mhaberler> for lack of a better name for now
[08:43:49] <KimK> Thanks for reminding me of your post, I'll save it locally for reference.
[08:44:45] <mhaberler> #4 is likely hard, too
[08:49:59] <KimK> Yes, that threading retract sounds interesting, I'm not familiar with that one, though.
[09:02:29] -!- JT-Shop-2 [JT-Shop-2!~John@184.20.140.167] has joined #linuxcnc-devel
[09:02:29] -!- JT-Shop has quit [Read error: Connection reset by peer]
[09:02:30] -!- jthornton-2 [jthornton-2!~john@184.20.140.167] has joined #linuxcnc-devel
[09:02:30] -!- jthornton has quit [Read error: Connection reset by peer]
[09:09:35] -!- micges [micges!~micges@ddv183.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[09:15:20] -!- Thetawaves has quit [Ping timeout: 260 seconds]
[09:19:32] -!- adb [adb!~adb@178-211-226-40.dhcp.voenergies.net] has joined #linuxcnc-devel
[09:32:29] -!- micges has quit [Quit: Leaving]
[09:41:00] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[09:48:29] -!- sumpfralle has quit [Quit: Leaving.]
[09:59:49] -!- mk0 has quit [Ping timeout: 248 seconds]
[10:15:17] -!- bassogigas has quit [Quit: LinuxCNC 2.5.0!]
[10:29:00] -!- factor has quit [Ping timeout: 260 seconds]
[10:54:37] jthornton-2 is now known as jthornton
[11:03:26] -!- sumpfralle has quit [Quit: Leaving.]
[11:20:26] -!- WillenCMD has quit [Ping timeout: 245 seconds]
[11:23:40] -!- robin_sz has quit [Ping timeout: 260 seconds]
[11:39:45] -!- skunkworks__ has quit [Ping timeout: 256 seconds]
[12:02:46] -!- adb has quit [Ping timeout: 265 seconds]
[12:17:57] -!- vladimirek has quit [Remote host closed the connection]
[12:23:35] -!- jthornton has quit [*.net *.split]
[12:23:35] -!- iwoj has quit [*.net *.split]
[12:23:35] -!- phantoneD has quit [*.net *.split]
[12:29:05] -!- jthornton [jthornton!~john@184.20.140.167] has joined #linuxcnc-devel
[12:30:19] -!- skunkworks has quit [Ping timeout: 260 seconds]
[12:38:16] -!- skunkworks [skunkworks!~chatzilla@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[12:52:28] -!- iwoj_ has quit [Quit: Textual IRC Client: http://www.textualapp.com/]
[13:11:05] -!- psha[work] has quit [Quit: Lost terminal]
[13:18:06] <cradek> interesting discussion since I was here last
[13:18:19] <cradek> obviously rotation+offset is not commutative
[13:19:00] <cradek> to get from gcode coords to machine coords, you offset by g5x and tool, then rotate, then offset by g92
[13:19:50] <cradek> I am pretty sure you can move these operations into motion, and maybe the only casualty will be soft limits
[13:20:18] <cradek> adding a new offset first is an interesting idea
[13:21:10] <cradek> how to get G10 to work right again might be a problem that we need to understand before starting maybe?
[13:21:43] <cradek> I'll be in and out today, I will read back, bbl
[13:41:51] -!- n2diy__ has quit [Quit: Ex-Chat]
[13:49:09] -!- Rogge [Rogge!~IceChat77@mail.tormach.com] has joined #linuxcnc-devel
[13:57:43] -!- maximilian_h [maximilian_h!~bonsai@130.255.104.157] has joined #linuxcnc-devel
[13:57:51] -!- maximilian_h [maximilian_h!~bonsai@130.255.104.157] has parted #linuxcnc-devel
[14:00:45] -!- mhaberler has quit [Quit: mhaberler]
[14:03:14] -!- maximilian_h [maximilian_h!~bonsai@130.255.104.157] has joined #linuxcnc-devel
[14:03:17] -!- maximilian_h [maximilian_h!~bonsai@130.255.104.157] has parted #linuxcnc-devel
[14:22:40] -!- mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[14:25:54] JT-Shop-2 is now known as JT-Shop
[14:26:36] <mhaberler> cradek: I read up a bit on rotation in the code and the wiki; I assume you did it the rotation axis goes through the current point?
[14:26:51] <mhaberler> assume as you
[14:29:00] <mhaberler> re: 'get G10 to work right again': let me understand the current processing and the impact of a new offset first
[14:30:17] <mhaberler> I guess the current offsetting is: gcode coord + g92off + g5xoff + opt_tool_offset; here, rotate the programmed point as per G10 - correct?
[14:31:23] <mhaberler> now comes the new offset. let's assume for now it is applied like so:
[14:31:55] <mhaberler> (gcode coord + g92off + g5xoff + opt_tool_offset) * rotation(programmed point) + new_offset
[14:31:55] <skunkworks> cradek set this order 'you offset by g5x and tool, then rotate, then offset by g92'
[14:32:10] <mhaberler> aha.
[14:33:11] <mhaberler> so we have (current_point + g5xoff + tooloffset) * rotation(pp) + g92offset ?
[14:33:19] <skunkworks> (to get from gcode coords to machine coords)
[14:33:24] <mhaberler> right
[14:33:36] <mhaberler> current_point = myspeak for gcode coord
[14:34:27] <mhaberler> from that I get g92offset isnt rotated, so the new offset could be likewise
[14:34:30] <mhaberler> we'd have:
[14:34:41] <mhaberler> (current_point + g5xoff + tooloffset) * rotation(pp) + g92offset + newoffset
[14:36:55] <skunkworks> what is the new offset?
[14:37:26] -!- psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[14:37:40] <skunkworks> wouldn't it have to be tool dependant? (if you do a tool change - the next tool would not have the 'new offset' or am I miss-understanding?
[14:37:41] <cradek> perhaps you want two new offsets and a new rotation?
[14:37:42] <mhaberler> the experimental vehicle I mentioned, with the only provision that it be applied in motion ONLY and thus is changeable there during jog-while-paused; proof of concept
[14:38:38] <mhaberler> if one were to use that experimental offset as a tool offset as changed during pause, you could commit it to the tool table at the end of the program
[14:39:27] <mhaberler> after which interp is again in sync with the actual tool as then reflected in the tt
[14:40:21] <mhaberler> two new offsets, new rotation: stunned bunny look here
[14:40:47] <cradek> well you will eventually need them all
[14:40:55] <cradek> also I think you will have to delay feed calculations
[14:41:27] <mhaberler> oh, as an extended experiment, fine
[14:41:33] <mhaberler> why delay feed?
[14:41:54] <cradek> because you no longer know the lengths of moves at interp time
[14:42:12] <cradek> so inverse time mode can't be changed to feed per minute at interp time anymore
[14:44:18] <mhaberler> I might be missing something - why does the introduction of a new offset invalidate the move length calculation? (note invariant of the current pause-jog-resume stuff: there's a return move to the point where the original move was paused)
[14:45:34] <mhaberler> the new offset might change the return move (actually it better do if its a tooloffset ;) but thereafter I dont see the change yet
[14:45:43] <cradek> consider a move like G53 G1 Z0
[14:45:48] <mhaberler> ok
[14:46:02] <mhaberler> ah.. I see
[14:46:27] <mhaberler> then you do a feed move from there including the new offset and thats why the feed changes
[14:46:46] <cradek> new tool tip goes back to the original position, machine joints are now in a different position
[14:47:48] <cradek> I guess I mean something like G93 F1 G53 G1 Z0
[14:48:22] <mhaberler> right
[14:48:46] <cradek> do you think we will lose the ability to tell at interp time whether the program will go out of bounds (even in the usual case of no offset changes during run)?
[14:49:19] <cradek> this is not necessarily bad because it is an existing problem for kins machines
[14:49:30] <cradek> (but it hurts a bit to think we'd lose it for normal machines)
[14:50:32] <cradek> hm, we need all the separate origins in motion, and we need to delay all endpoint calculations
[14:51:06] <mhaberler> I think in the general case you'd lose that property at interp time; it would go both ways though, a program failing at interp time could theoretically be valid for the machine; not that this helps anything
[14:51:37] <cradek> consider a program like G54 G1 X1; G55 Y2; G56 Z3; G92 X1; G92.1 X1
[14:54:53] <mhaberler> I think the endpoint can be calculated in task with the current newoffset EXCEPT during pause-and-jog; that'd be a motion time check
[14:56:16] <cradek> but I hope we can have the offsets in only one place :-/
[14:56:19] <mhaberler> (btw: http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/secondary-motion-queue-plus-kenlerman-idea : I fixed the abort-during pause, resume issues; it's good for a try now)
[14:56:36] <mhaberler> technically its a queue buster
[14:57:06] <cradek> no offense but I'm not really interested in messing with your interim solution that uses extra panels and hal components etc
[14:57:09] <mhaberler> although one might choose to ignore that and defer checking to motion
[14:57:10] -!- factor has quit [Ping timeout: 260 seconds]
[14:57:11] <cradek> it's a distraction
[14:57:14] <mhaberler> fine
[14:58:09] <mhaberler> I didnt get the point with the G54 G1 X1; G55 Y2; .. program?
[14:59:02] <cradek> motion has to know all those offsets separately and the endpoints can't be calculated without that knowledge
[14:59:25] <mhaberler> oh. I see.
[14:59:31] <cradek> and remember each one has its own rotation too
[15:00:05] <cradek> so each of those moves is in a direction along a different rotated axis, so it changes only the one stated coordinate in that current g5x system
[15:00:13] <cradek> all that endpoint calculation has to be delayed
[15:00:56] <cradek> this means making motion very knowledgeable about gcode peculiarities
[15:02:51] <cradek> in other words we're moving half the gcode interpreter into realtime
[15:03:06] <cradek> I'm not saying that's bad, but we should acknowledge what that loses us
[15:03:28] <cradek> (and gains)
[15:03:37] <mhaberler> moves would have to carry a coordsystem tag then
[15:04:08] <cradek> yes I think so
[15:04:24] <cradek> and a tool number maybe?
[15:04:52] <mhaberler> well, while you are at it..
[15:04:53] <mhaberler> +
[15:05:50] <cradek> the entire var file and tool table?
[15:06:17] <cradek> looking at find_ends(), I think this is a lot of what needs to be delayed
[15:06:35] <cradek> hm, how to handle polar coords is an interesting question too
[15:08:44] <mhaberler> note that 'delaying' doesnt necessarily mean 'in kernel'
[15:09:13] <cradek> but that's where the last queue is
[15:09:20] <cradek> (and it has to be)
[15:09:49] <cradek> I think the idea is to commit to offsets/endpoints after the last queue so it can be changed without damaging the queues?
[15:09:51] <mhaberler> you mean the tp motion q?
[15:09:54] <cradek> yes
[15:10:23] <mhaberler> yes, thats the idea; that would probably give you step back, too
[15:10:42] <cradek> step back?
[15:11:08] <mhaberler> stepping back the motion q, provided consumed elements arent immediately overriden
[15:11:30] <cradek> oh
[15:11:43] <mhaberler> the EDM case
[15:12:01] <cradek> people sometimes talk about being able to replay only part of a move - I think that's fraught
[15:12:48] <cradek> is this a separate issue we should avoid talking about now?
[15:13:04] <mhaberler> why not
[15:13:11] <cradek> brb
[15:13:21] <mhaberler> ok, I'll be back in 30mins too
[15:14:45] <mhaberler> but still I'd be interested to learn where you see the problem there (blending.. that I'd guess be difficulter to step back)
[15:19:10] <skunkworks> mhaberler: wouldn't and edm case want to walk back along the path? (I am not sure)
[15:19:42] <skunkworks> like running the gcode in reverse? (maybe that is what you are saying_
[15:28:25] <cradek> http://www.linuxcnc.org/docs/html/gcode/coordinates.html was written before rotation
[15:29:17] <cradek> I can't find the polar coordinate docs
[15:30:03] <cradek> I think polar translation is another part of what needs to be delayed
[15:31:41] -!- ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[15:31:44] <cradek> and I'm also worried about canned cycles
[15:32:40] <cradek> if in the middle of a G91 X1 L10 set of cycles, what should happen if I change offsets?
[15:32:52] -!- Nick001 has quit [Ping timeout: 246 seconds]
[15:32:54] <cradek> say I change Y
[15:35:22] <cradek> aha, found polar: http://www.linuxcnc.org/docview/html/gcode/overview.html#_polar_coordinates
[15:43:43] <mhaberler> skunkworks: yes
[15:43:50] <mhaberler> thats what I meant
[15:45:47] <skunkworks> neat
[15:46:04] <mhaberler> postpone polar: because of angle change due to rotation?
[15:46:45] <cradek> consider G91 G1 @1 (move away from the origin such that the radius gets 1" longer, preserving the angle)
[15:47:04] <cradek> moving the origin changes this move (or makes it indeterminate!)
[15:48:41] * skunkworks sees a jog wheel hooked up to 'program.flow' and be able to run the program forward and backwards.. ;)
[15:49:03] * cradek sighs
[15:49:12] <skunkworks> cradek: sorry ;)
[15:52:56] <cradek> I hope mhaberler didn't have a heart attack :-)
[15:53:03] <mhaberler> no
[15:53:55] <mhaberler> not yet, that is;)
[15:55:00] -!- factor has quit [Read error: Connection reset by peer]
[15:56:38] <mhaberler> you'll probably dont like this, but there is always the option of deprecating features. For instance, I would deprecate the computed oword subroutine name immediately.
[15:58:01] <cradek> is that a problem that makes delayed offsets harder?
[15:58:36] <mhaberler> no, not in this context, but it kills any attempt for static path analysis
[15:58:49] <mhaberler> disregard
[15:59:23] <cradek> gladly
[16:03:02] <mhaberler> re 'gcode aware motion': we have two things that would move in the pipeline. First, application of offsets, and rotation. Endpoint and limit calculation, and feed. Those are not yet per-se language specific; their application order is. I would assume any other language, like the mythical apt360 for instance, would have offsets, maybe rotation; not necessarily in the same application order.
[16:04:01] <cradek> also the special handling of null words
[16:04:20] <cradek> I agree other languages probably have some of those things in common and some not
[16:04:25] <mhaberler> Second, elements of _setup which become subject to motion-time changes. Those clearly are language dependent. With a bit of care the first part can be made generic enough to cater for another application sequences.
[16:04:49] <mhaberler> null words?
[16:05:07] <cradek> the special value that means it's unspecified
[16:05:18] <cradek> talked about yesterday?
[16:05:29] <mhaberler> I see. None in rs274.
[16:05:58] <cradek> ?
[16:06:00] <mhaberler> Python 'None', that is.
[16:06:08] <cradek> oh right, ok
[16:06:24] <mhaberler> Well null values are quite common across languages; their meaning might not be
[16:06:48] <cradek> yes I mean that's a gcode peculiarity that will have to be in motion
[16:07:09] <mhaberler> like interpret as zero, a failure, as do-not-apply-at all might be language specific
[16:07:49] <cradek> if we're delaying finalizing endpoints we also have to delay crc until AFTER that, right?
[16:08:31] <mhaberler> I would think so, yes
[16:08:44] <cradek> which would be good because it means you can change radius without destroying everything
[16:09:45] <cradek> (glossing over how radius changes can make the path become impossible)
[16:10:31] <mhaberler> conceptually it has to be after an offset/rot change, but it is precomputable again until the next change
[16:11:19] <cradek> not sure I follow that
[16:11:59] <mhaberler> would you like to incude radius change in the discussion at that point?
[16:12:34] <cradek> if we've delayed crc until after the final queueing, then it's trivial
[16:12:56] <cradek> I have a thought experiment
[16:13:44] <cradek> what is the bare minimum part of the interpreter that could NOT be moved into realtime/kernel space? what is the MOST gcode interpretation that we can delay until the very end?
[16:14:44] <cradek> if we had the interpreter of 10 years ago with linear flow and no malloc, it seems like ALL of it could be done in realtime
[16:15:06] <cradek> but not anymore, since we have file seeks etc
[16:15:07] <mhaberler> yes, a linear gcode machine is definitely worth some thinking
[16:15:42] <cradek> but perhaps the userland part could only unroll loops and substitute variables
[16:15:50] <mhaberler> exactly
[16:16:19] <cradek> I always think "well that was easy in the paper tape days" when you read one block of gcode, analyze it, and issue a move, then repeat
[16:16:44] <mhaberler> canon might be an unnecssary loss of information, yes
[16:16:47] <cradek> but what if we send our (reconstructed) paper tape over nml or whatever
[16:17:38] <cradek> it means no different interpreter plugins
[16:17:44] <mhaberler> I think the oword, variables etc stuff should not move
[16:17:46] <cradek> it means AXIS becomes harder to write
[16:18:00] <mhaberler> no it doesnt necessarily; gcode is a legit intermediate code
[16:18:13] <cradek> ok, point taken
[16:18:25] -!- tiago has quit [Remote host closed the connection]
[16:18:37] <cradek> but AXIS has to interpret gcode now instead of canon calls
[16:18:52] <mhaberler> you're talking preview?
[16:18:56] <cradek> yes
[16:19:07] <mhaberler> duh
[16:20:48] <mhaberler> you might have a dummymotion instead of a dummy canon; maybe they are even the same, just different modes
[16:21:51] <mhaberler> assume a 'gcode motion machine', and it has to modes: move metal, and feed axis. o?
[16:22:03] <cradek> I'm not sure crc can be delayed and done in realtime. for some programs it may need to grow arbitrarily.
[16:22:28] <mhaberler> grow.. size of offset curve?
[16:22:48] <cradek> no, queue of motions
[16:23:08] <cradek> well I guess the fix to that is pick a max and just abort
[16:23:19] <mhaberler> how is that different from the queued canon length?
[16:23:39] <mhaberler> even now the motq is in a userland-accessible shm segment
[16:23:40] <cradek> there's no maximum in the userland implementation
[16:23:57] <cradek> different queue
[16:24:14] <cradek> I'm talking about the crc queue in interp_queue.cc
[16:24:18] <mhaberler> yes
[16:24:38] <cradek> apparently that would all have to be in motion
[16:24:57] <mhaberler> triggered by, and accessible by motion, yes
[16:25:49] <mhaberler> would the following be feasible: doing say a fixed amount of crc offset curve segments, move metal, compute next amount and blend (note overlap requirement -> a thread could do it)
[16:26:16] <mhaberler> actually a thread could do it driven by queue space
[16:26:30] <cradek> what is move metal?
[16:26:37] <mhaberler> drive the machine
[16:26:43] <mhaberler> off the motionq
[16:27:31] <mhaberler> iow: is there a requirement to do the complete, arbitrary crc offset curve in advance or can it be done in parallel or some amount ahead of motion?
[16:27:32] <cradek> if in realtime you'd want to do the bare minimum of reading ahead, only one or a few moves of readahead are usually required for crc
[16:28:00] <mhaberler> that's what I guessed
[16:28:12] <cradek> crc is all about figuring out where the next "corner" is
[16:28:26] <cradek> usually you only need the move you're about to make, and the one after that
[16:29:02] <mhaberler> so in terms of actual requirements it doesnt require unbound lookahead on the motionq
[16:29:05] <cradek> more precisely, you need the two moves that form the corner you see when projected onto the comp plane
[16:29:18] <cradek> well yes it does in the general case, but you can just abort if it gets too bad
[16:29:33] <cradek> consider move into corner, up and down a zillion times, then continue on to next corner
[16:29:41] <cradek> then you need to know zillion+2 moves
[16:29:41] <mhaberler> oh I see
[16:29:57] <cradek> (it currently handles that)
[16:30:23] <cradek> for instance a drill cycle can make MANY up/down moves
[16:30:27] <mhaberler> so its either 'abort if too much lookahead required' or 'compute in parallel with a bound lookahead'
[16:30:38] <cradek> yes I think so
[16:31:57] <cradek> maybe we need to develop a spec for our virtual paper tape language
[16:32:10] <mhaberler> if you pause/change tools during crc, the lookhead q is invalidated and needs to be recomputed
[16:32:40] <mhaberler> it needs to be dumb as ape….t
[16:32:41] <cradek> yes I'd have to ponder what changing radius does
[16:33:19] <mhaberler> well if you know in advance this is bound to happen, then its a whole different story than grafting on ex-post
[16:33:23] <cradek> we want to be able to pause and resume during a VPT block, and we want to be able to change offsets/rotations between them? or during?
[16:33:25] -!- stevegt_1 has quit [Ping timeout: 260 seconds]
[16:33:40] <mhaberler> vpt..?
[16:33:45] <cradek> virtual paper tape language
[16:33:45] <mhaberler> virtual paper tape
[16:33:48] <mhaberler> get it
[16:34:06] <mhaberler> during them. moves might be very long.
[16:34:17] -!- A0Sheds has quit [Read error: No route to host]
[16:34:41] <cradek> during is scary
[16:34:55] <mhaberler> btw - why did you say: stepping back a move partially is 'fraught'?
[16:35:00] <cradek> if I have that G91 G1 @1 and I move the origin during the move, what happens to it?
[16:35:53] <cradek> I don't see how you can finish a general move after changing an offset, because the old current point probably isn't even on the new move anymore
[16:35:54] <mhaberler> I think within a move, the options could remain limited
[16:36:32] <cradek> for some it is -- like changing tool LENGTH only and then resuming an XY only cut
[16:36:36] -!- A0Sheds has quit [Changing host]
[16:36:46] <cradek> but I think the general case doesn't work out at all
[16:37:25] <mhaberler> that is equivalent to a self-modifying program
[16:37:45] <mhaberler> not that it helps solving, but you get real bad grades in CS for doing that
[16:38:01] <cradek> maybe detect-and-abort is our friend
[16:40:29] <mhaberler> lets look at the bigger picture for a moment. Assume you move interp minus oword between task and motion, or into motion.
[16:40:47] <mhaberler> the current interp would be a file reader.
[16:41:02] <mhaberler> task feeds mdi-style vtp commands off this file.
[16:41:06] <cradek> yes file reader/VPT-builder
[16:42:05] <mhaberler> now, axis.
[16:42:22] <cradek> AXIS needs to understand VPT language as well
[16:42:33] <mhaberler> thats not yet clear
[16:42:48] <mhaberler> lets assume the vtp machine has two modes, simulate and move the machine.
[16:43:17] <mhaberler> now in sim mode, you could tap into the vtp machine at different layers. You are assuming duplicating the vtp input
[16:43:20] -!- robin_sz has quit [Ping timeout: 260 seconds]
[16:43:42] <mhaberler> but note that with the interp move behind task also canon moves, or whatever is left of it
[16:43:48] <cradek> ok I follow you. vpt reader could be somewhat modular and have something like the current canon at some level
[16:43:55] <mhaberler> axis could hook there
[16:44:46] <cradek> ok the vpt->canonish part needs to be able to work in userland and kernel
[16:44:52] <mhaberler> or it could actually hook at the hal level, given some clock for looking at it
[16:45:11] <mhaberler> there could be a simulated hal output for preview
[16:45:34] <cradek> nah, you need entire moves for preview, not a set of positions along them
[16:45:46] <cradek> you need canonish commands
[16:46:29] <mhaberler> I didnt say the clock is async to the interp; it could signal when a move is done; or you feedback the equivalent of canon into a vtp->axis q
[16:47:25] <mhaberler> why is it that axis needs to know, cant we just do the gl part in the vtp ;-?
[16:47:52] <mhaberler> okok, I admit it is fattening fast
[16:48:28] <mhaberler> preview outside the UI has some charms for UI writers
[16:48:30] <cradek> I think vpt->(crc etc)->canonish is a necessary layer
[16:49:16] <mhaberler> fine, so it's just a different output for preview feedback
[16:51:24] <mhaberler> what is left of NML?
[16:52:03] <mhaberler> reason why am asking:
[16:52:04] <cradek> maybe nml still talks to guis and now transports the vpt? I dunno
[16:52:53] <mhaberler> if you look at it, there are really 2 modes of operation: sending commands RPC-style or enqeueing them, second: status feedback
[16:53:05] <mhaberler> now 1) has been solved a gazillion times, and better.
[16:53:06] <cradek> yes
[16:53:33] <cradek> I have no particular love for nml but I'm scared at how big your rewrite is becoming
[16:53:37] <mhaberler> for 2) if you look at it, what is mostly needed: mindless copying between hal pins (or information that could be in hal) to and from NML messages
[16:53:48] <mhaberler> we are at the tought experiment level
[16:53:54] <cradek> right
[16:53:59] <mhaberler> all linuxcnc3
[16:54:09] <mhaberler> back to 2):
[16:54:19] <cradek> it's kind of interesting to think that gui feedback could be hooked up via hal
[16:54:48] <cradek> we lose nml-gui-over-network but that sucks anyway
[16:54:48] <mhaberler> I'd think a 'remote HAL' addon takes the mindless copying back and forth out of NML, technically its a media break
[16:55:21] <mhaberler> but with the right rpc mechanism it is streightforward to replace and better living ever after
[16:55:49] <mhaberler> have a look at google procotol buffers in a quiet moment
[16:56:23] <mhaberler> the key drawback is that it doesnt support userdefined data types which HAL pins would be (since they are pointers)
[16:56:30] <mhaberler> but I'm getting off track
[16:57:17] <cradek> and I'm getting a headache
[16:57:29] <mhaberler> thanks god its friday
[16:57:33] <cradek> off to find some drugs before it sets in worse
[16:57:40] <mhaberler> all the best
[16:59:16] <mhaberler> HAL, if anything, is one of the strongest parts in linuxcnc, and it is worth putting some thinking into leveraging on it
[16:59:32] <cradek> ok
[17:00:21] <cradek> yes it'd be interesting if guis would get all their feedback from hal somehow
[17:00:38] <cradek> yikes how did we get here from changing offsets?
[17:01:15] <mhaberler> the power of creativity etc etc
[17:01:23] <skunkworks> is that a surprise? ;)
[17:02:09] <cradek> I'm back to the realization that allowing changing offsets during pause is almost a complete rewrite
[17:03:06] <cradek> I think the vpt->offsets/crc/etc->canonish that can be done in realtime is the key
[17:03:35] <cradek> you'd just link that into AXIS too and suddenly AXIS can understand vpt as well
[17:04:04] <cradek> and other neat things like AXIS could show both the programmed and crc-offset path
[17:04:20] <cradek> where it currently has no clue because that information is gone
[17:04:34] <mhaberler> I think I know where you headache comes from ;)
[17:05:09] <cradek> I think that's the most coherent design we've found so far
[17:05:38] * skunkworks cheers from the cheap seats
[17:05:56] <cradek> now all we need is some programmers to "task" our "action items" to :-)
[17:06:39] <mhaberler> a 'virtual all-hands get-together' on the mailing list will solve that
[17:07:00] <cradek> your optimism makes me smile
[17:07:17] <mhaberler> I was punning on management bullshit bingo
[17:07:33] <cradek> haha
[17:08:05] <skunkworks> wonder who will be the paulc and poo poo it all - get upset and leave. (like the hal change) ;)
[17:08:22] <cradek> maybe me! :-)
[17:08:33] <skunkworks> NOOOOOooooooo!!!
[17:10:17] <cradek> what do we need next? a vpt language spec and a list of what we want to allow to be changed during and between vpt blocks?
[17:10:19] <skunkworks> So - merge JA3, rewrite everthing.
[17:10:37] <mhaberler> q: will be vtp be queuebuster-free?
[17:12:55] <cradek> bbl, lunch
[17:13:02] <mhaberler> good answer
[17:19:12] -!- phantoxe has quit []
[17:27:11] -!- the-jub has quit [Remote host closed the connection]
[17:42:52] jdhnc is now known as jdhNC
[17:45:26] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 11.0/20120310193829]]
[17:53:34] -!- cmorley has quit [Quit: Leaving.]
[18:14:02] <cradek> I think things that were previously queue busters won't be in the vpt language. you'll just have one pt before, and it runs out, and then you get another one later
[18:20:12] -!- sumpfralle has quit [Remote host closed the connection]
[18:27:52] <cradek> I don't know how probing will work
[18:37:40] -!- uwe_ has quit [Ping timeout: 246 seconds]
[18:43:20] -!- andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[18:44:07] -!- andypugh has quit [Client Quit]
[18:44:23] -!- andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[18:46:07] <mhaberler> is vpt the language presented to the user, or is it a intermediate language generated by the 'user side language'?
[18:46:25] <cradek> imo vpt does not have to be user-compatible
[18:46:56] <cradek> and it probably shouldn't be - it should be more like a machine representation of a parsed gcode block
[18:47:05] <cradek> something like the interp's block struct
[18:47:10] <mhaberler> right
[18:47:15] <cradek> doing string parsing in kernel is stupid
[18:47:21] <mhaberler> definitely
[18:48:11] <cradek> how would probing work?
[18:48:18] <mhaberler> so the queuebusters would be a UI thing - the interpl becomes a 'vtp parsed block' list
[18:48:37] <cradek> yeah seems like
[18:49:12] <mhaberler> ui: send vtpblock with probe command, wait for completion, inquire status
[18:49:25] <mhaberler> ?? not sure
[18:50:17] <cradek> will vpt language know about variables? offsets are kind of a special case of variables
[18:50:21] <mhaberler> the question really is: what is done with the probe result, and where does it go if outside
[18:50:44] <cradek> it goes back to the user as ngc variables
[18:52:46] <cradek> the vpt-consuming machine must have a readout of some kind
[18:53:04] <mhaberler> variables: accessing yes, parsing: no - so we're talking a shared variable space
[18:53:06] <cradek> for the ngc interp (and perhaps guis?) to read
[18:53:39] <cradek> wait you think the vpt machine should be able to read ngc variables?
[18:54:30] <mhaberler> not in the sense of parsing, but as far as params drive execution they have to
[18:54:56] <cradek> once the pt is made (queued) the ngc state that generated it is gone, isn't it?
[18:55:51] <mhaberler> if the frontend uses control structures, that would be same situation as with motion line numbers now
[18:56:08] <mhaberler> no 1:1 relation or backref into the source context
[18:56:16] <mhaberler> (as things stand now, that is)
[18:56:49] <mhaberler> let me diverge for a minute on a hal-compatible messaging model; it is a young idea so be patient
[18:57:00] <cradek> source context of vpt blocks seems unrelated to variable access
[18:57:06] <mhaberler> yes
[18:57:24] <mhaberler> but for source display on the UI you'd need the backref
[18:57:37] <cradek> ok, vpt language will have a fancy kind of N word
[18:57:52] <mhaberler> right, 'N' on steroids.
[18:58:01] <cradek> but I don't see how that affects ngc variables
[18:58:15] <mhaberler> no, it doesnt. disregard for now.
[18:58:21] <cradek> will every vpt block contain all the variables?
[18:58:23] <cradek> oh ok.
[19:00:12] <mhaberler> I think the division line will be something like in python or basic, where you have a parsing phases translating into a vm code, and that code is executed - the parsing and execution need a shared variable model I would think
[19:00:57] <andypugh> Ah, you are inventing a G-code byte code?
[19:01:14] <mhaberler> what's a parsed block other than that?
[19:01:45] <andypugh> I don't know, I got lost in a maze of NML messages and classes, all alike, when I tried to figure it out.
[19:02:19] <mhaberler> the difference though is: if you want to retain the 'no control structures' requirement in the vtp machine, then those need to be elsewhere
[19:02:34] <cradek> yes that's my feeling too
[19:02:58] <cradek> yet the vpt machine must maintain offsets/origins/rotations/tooltable
[19:03:01] <andypugh> So, would it be a completely unwrapped version of the g-code?
[19:03:30] <cradek> andypugh: yes a simplified unwrapped gcode that you can interpret a block at a time (or close to that) in realtime
[19:03:41] <mhaberler> it probably helps to assume a completely different frontend language, and see how it fits in.
[19:03:44] -!- robin_sz has quit [Ping timeout: 246 seconds]
[19:03:57] <cradek> possibly
[19:04:15] <cradek> it's only a new kind of canon level that supports the things we need, like knowing which words are specificed and which aren't
[19:04:28] <mhaberler> for instance, lets assume the UI language is python, and gcode goes like so G("G1 x2 y3") and other than that its bona fide python.
[19:04:42] <andypugh> Hmm, so we could have modular interpreters. I think this sounds very interesting, and rather EMC3.
[19:05:07] <cradek> andypugh: yes if crc and tool table handling etc happened after this level, different interps can be much simpler
[19:05:15] <mhaberler> now for the variable model: you'd have param[5070] for your probe result. this implies shared memory between language frontent and vtp machine.
[19:06:03] <mhaberler> in theory you could layer RPC inbetween but it will be a real dog
[19:06:15] <mhaberler> and I dont see the point given todays machines
[19:07:00] <cradek> brb
[19:07:05] <mhaberler> for the occasional command thats fine, just like emcrsh
[19:07:06] <mhaberler> sure
[19:09:37] <mhaberler> I recently looked if the python virtual machine is extensible, but that is a huge dependency and not necessarily kernel compatible
[19:10:58] <mhaberler> basically the UI language implodes to the parsing layer plus checks which can be made at that point
[19:11:45] <andypugh> Looks like I might be learning Python just in time to help.
[19:12:04] <mhaberler> yes, that was a wise decision - feeling comfortable yet?
[19:12:28] <andypugh> Not at all :-)
[19:13:21] <mhaberler> yes, the initial pains are substantial; took me a while to grasp the variable (aka name for reference) model
[19:17:02] <mhaberler> I digress a minute on the messaging theme. We will still need it because I think the single machine model/all shared is not a wise decision
[19:19:12] <mhaberler> now lets assume for a minute that all the stuff going in, or out via messages goes to/from HAL variables. In that case, the construction of the message can be derived from the HAL names in question (read as a) automatic message construction giving the laundry list and b) not necessarily compiled)
[19:20:11] <andypugh> HAL or just shared-memory?
[19:20:54] <mhaberler> HAL would have the advantage of having named and typed shared memory, so those two aspects enable the automatic message construction
[19:22:06] -!- ve7it has quit [Remote host closed the connection]
[19:22:07] <mhaberler> in a program you'd request a status update of foo.bar and motion.joint.2.something at the abstract naming level; the rest is automatic
[19:22:59] <mhaberler> this is no different for instance from name resolution in shared libraries
[19:23:14] <andypugh> We might need more datatypes
[19:23:39] <andypugh> But this is not the time for implementation details
[19:23:43] <mhaberler> that is a downside of hal, yes. no strings, no compounds.
[19:24:10] <mhaberler> strings are straighforward; structs can be unrolled.
[19:24:12] -!- mazafaka has quit [Ping timeout: 245 seconds]
[19:25:07] <mhaberler> but representing machine state exclusively in HAL has some very nice properties wrt debugging, UI..
[19:25:22] <andypugh> Halscope...
[19:26:23] <mhaberler> right. If you read motion code, obviously such an attempt was in progress at some point in time, to get around the permanent copy in/copy out from messages (which were sitting in the same shared memory segment to start with)
[19:26:24] <cradek> are you proposing that the vpt is fed in via hal pins?
[19:26:32] <mhaberler> no definitely not
[19:26:56] <mhaberler> as a unified machine state representation, but not as a command queue
[19:27:33] <mhaberler> queues have their place an there's no point forcing that into hal
[19:28:32] e-ndy is now known as e-ndy|afk
[19:30:57] <mhaberler> one point wrt to vtp semantics warrants a deeper look, that is: is it 1:1 byte code model of the current rs274ngc language, OR is it supposed to be a intermediate language to support one or more different rs274ngc-alike languages.
[19:31:48] <mhaberler> a good point to look at is this self-modifying behaviour wrt cycles. would you assume the current cycle model is in vtp 1:1?
[19:32:06] <cradek> it ought to be an intermediate smart language
[19:32:23] <cradek> for instance it doesn't need to handle more than one arc format, like gcode does
[19:32:39] <cradek> in fact it should handle a more generic arc
[19:33:05] <mhaberler> so is it a 'canon on steroids' machine?
[19:33:16] <mhaberler> driven by blocks?
[19:33:30] <cradek> yes I think it's still very much like canon, but supporting more things that we need
[19:33:54] <cradek> for instance canon doesn't let you say "move X to 1.234 and don't move any other axes", which is something we need
[19:34:03] <mhaberler> right
[19:34:50] <mhaberler> in coord system 'foo' and the vtp would know what to do with 'foo'
[19:35:03] <mhaberler> currently it doesnt
[19:35:20] <cradek> yes
[19:35:51] <mhaberler> lets come back to the cycle. will it do cycles, or just process moves?
[19:36:38] <cradek> the answer to that probably depends on the design wrt changing vpt machine parameters (offsets) during ngc cycles
[19:36:51] <cradek> and I don't know what that design should be
[19:39:35] <mhaberler> it could be that some internal state is subject to offset application; if there's a way to pass a block saying 'start here, and btw if offsets change, change 'here' as well'
[19:39:43] <mhaberler> not sure if this solves the issue
[19:40:52] <mhaberler> maybe the way to do this is not to pass values, but references (or names), and the semantics is in the type of the name
[19:41:32] <cradek> I don't even know what the behavior/motion should be in these cases, I don't care about implementation yet
[19:42:27] <cradek> while a vpt is running, maybe it only makes sense to allow tool offsets, not coordinate systems, to change.
[19:43:02] <mhaberler> that would simplifiy things a lot
[19:43:40] <cradek> in that case does the vpt machine need to handle origins at all?
[19:44:00] <cradek> if it didn't have multiple origins at all, it seems like that might be nice
[19:44:06] <mhaberler> for instance, a repeated G92 application could just be unrolled into serial executions
[19:45:01] <mhaberler> how does that fare with current language semantics?
[19:45:15] <mhaberler> currently you can change offsets mid-flight at will
[19:45:27] <cradek> I'm not following
[19:46:08] <mhaberler> you're talking origins like g92, g5x etc?
[19:46:22] <cradek> yes
[19:46:53] <cradek> if we don't need to allow changing those while paused, does the vpt machine have to know about them at all?
[19:47:09] <mhaberler> its fine for me to have frozen origins at program start
[19:47:27] <mhaberler> I wonder if with that type of VM we'd be able to execute currently legit programs
[19:47:46] <cradek> I suspect some people use touch off g54 when they change tool lengths - users do weird things
[19:48:09] <cradek> but anyone can change :-)
[19:48:28] <mhaberler> rotation freeze, too?
[19:48:44] <mhaberler> I mean machines dont bend that often ;)
[19:48:51] <cradek> rotation is just like g5x imo
[19:49:37] <cradek> tool offsets have the nice feature that they don't rotate - they always apply in the same predictable direction
[19:49:55] <cradek> I think rotation handling must go right where g5x handling goes
[19:50:02] <mhaberler> aja, that was an open question i had - ticked off
[19:50:15] <cradek> and g92 handling goes in the same place too
[19:51:03] -!- vladimirek has quit [Remote host closed the connection]
[19:51:07] <mhaberler> so does this mean at program start: g92,g5x,rotation collapsed into a single offset/angle setting and frozen thereafter except for tool offset?
[19:51:40] <cradek> do you mean at a vpt run start?
[19:51:43] <mhaberler> yes
[19:52:02] <cradek> why would vpt know about them at all
[19:52:35] <mhaberler> you mean the whole thing understands only rotation, a single origin and tooloffsets?
[19:52:47] <cradek> if we don't need to change them during a run of a vpt, the vpt machine doesn't have to know about them
[19:52:55] <mhaberler> true
[19:53:15] <cradek> ... I think
[19:53:27] <mhaberler> that requirement translates into lots of bugs avoided
[19:55:49] <andypugh> I would like to touch-off into G54 in pause, and here is why. If a tool clogs on a stepper machine, you will tend to lose your origin when the steppers slip. You either need to be able to re-home or touch-off again to recover that.
[19:56:03] <mhaberler> so we have: user language X which 'executes', and that translates into one or more vtp segments/any other term here which 'run'
[19:56:31] <mhaberler> andypugh: that is a bit like tool offset, with the difference that this offset isnt committed to the tool table
[19:56:44] <mhaberler> at end of program
[19:56:52] -!- fliebel has quit [Remote host closed the connection]
[19:57:15] <andypugh> OK. just getting the requirement on the table
[19:57:27] <andypugh> brb
[19:57:28] <mhaberler> I get the point
[19:57:30] -!- andypugh has quit [Quit: andypugh]
[19:58:14] <mhaberler> I have it: vtp doesnt have 'segments', it has 'tapes' (tickers? strips? ;)
[20:00:08] <cradek> rehome during pause, wow
[20:03:03] -!- viesturs has quit []
[20:03:23] -!- phantoxeD has quit []
[20:04:32] -!- psha has quit [Quit: Lost terminal]
[20:04:37] <cradek> machine crashes and loses position sounds like time to start again
[20:05:16] <cradek> if the part melted and there are bits of broken tool stuck in it, you don't want to just start from the pause point and keep going do you?
[20:05:37] <cradek> I think rehoming is an excessive requirement
[20:05:52] <mhaberler> andy needs servos
[20:06:15] <cradek> even IF we want this requirement, it's rehoming that you want, not changing g5x
[20:06:57] <cradek> I am really not sure we need or want g5x/g92/rot change during pause.
[20:07:16] <mhaberler> I dont see the use case
[20:07:17] <cradek> it seems like those changes can easily invalidate moves, where tool offset changes don't
[20:07:42] <cradek> maybe the vpt machine has tool table data and nothing else
[20:08:12] <cradek> is that the smart split?
[20:08:40] <cradek> I've thought about this all day and I think I'm losing my grasp of all the trouble cases
[20:09:22] <mhaberler> that's ok. I'll be off for a month next week hiking, getting rid of the winter belly and clearing the head
[20:12:08] <mhaberler> so that would mean origins/rotation are UI state, and frozen at tape start
[20:12:32] <mhaberler> wrt tool info: yes, first class citizen of machine state
[20:12:41] <cradek> yes those are not on the vpt at all
[20:13:06] <mhaberler> now.. did we just go full circle..
[20:13:26] <cradek> I think you have bounds checking that's only off by the amount you change the tool during the vpt run then
[20:13:28] -!- andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[20:13:33] <mhaberler> right
[20:13:34] <cradek> well I was wondering that too, and why
[20:13:50] <cradek> maybe we should read back to the problem cases :-/
[20:14:05] <mhaberler> well, it came in because of origin/rot changes on the fly
[20:14:14] <cradek> yes true
[20:14:19] <cradek> and now we decided we don't want those
[20:14:36] <mhaberler> that is the difference, yes
[20:15:45] <mhaberler> it would be interesting to revisit how that freeze requirement impacts on current programs
[20:16:15] <mhaberler> and if it does, it can be detected by parsing
[20:17:39] <mhaberler> so far, the strategy was to maximize what can be changed, and wherever, with a major impact on tracking effort
[20:17:59] <cradek> I'm not sure what you mean by freeze
[20:18:21] <cradek> I'm imagining you can change offsets whenever you want during the ngc program, like now, it's just that the vpt machine doesn't know or care
[20:18:22] <mhaberler> no origin/rot changes after vtp tape start
[20:18:53] <cradek> I think we're not seeing the same thing here
[20:18:58] <mhaberler> so that would mean a ngc program would be split up into vtp tapes
[20:19:05] <cradek> no
[20:19:10] <mhaberler> ok, rewind
[20:19:53] <mhaberler> I guess I lost your point
[20:19:54] <cradek> the vpt machine doesn't know anything but world axis coordinates and tool offsets
[20:20:01] <andypugh> mhaberler: I am reminded of a maxim from the original Apple developers "Easy is Hard"
[20:20:25] <mhaberler> oh, I see.
[20:20:40] <mhaberler> you only move tool offsets into the vtp, and leave the rest in front.
[20:20:45] <cradek> if I manipulate ngc offsets and call a certain point 1,1 sometimes and -1,-1 later, who cares, to the vpt machine it's always 3.33,4.567
[20:20:53] <cradek> yes
[20:20:59] <mhaberler> aaaaah
[20:21:02] <cradek> why would the vpt machine care
[20:21:15] <mhaberler> fine
[20:21:16] <cradek> I might change g20/g21 too, vpt doesn't know or care
[20:21:40] <mhaberler> that sounds like move towards lower complexity to me
[20:23:08] <andypugh> So, "VPT" I was guessing "Virtual program trajectory" or something, but now I am thinking "Virtual program tape"?
[20:23:15] <cradek> virtual paper tape
[20:23:48] <cradek> it's a straight line program with blocks you can parse in realtime, fed into a simple type of machine that knows about tool offsets and (unfortunately) crc
[20:24:08] <mhaberler> that is a machine semantics I think I can grasp completely
[20:24:43] <mhaberler> I wasnt sure with the 'all origins/rot in vtp' model I'd completely get it
[20:25:32] <cradek> the vpt has one unit of measurement and one arc representation
[20:26:14] <cradek> I think it does not have variables
[20:27:01] <mhaberler> wrt to "tool offsets": I'd suggest theres an offset attribute which indicates "commit changed offset to tooltable at end of program"; there might be a valid use for a temporary offset not commited
[20:27:27] <mhaberler> re variables: the 1..5xxx thing?
[20:27:42] <cradek> yes, and we have named ones too
[20:27:58] <cradek> I'm not sure how the tool offsets get changed/invoked
[20:30:21] <mhaberler> re variables: I would think some execution result needs to be reflected in variables, and actually I think they would have a a warm place in shared memory; that is simpler than funneling back through a message (NML or otherwise)
[20:31:17] <mhaberler> for remote ui's there has to be a mechanism, and I think a clever rewrite of halremote does the trick
[20:31:21] <cradek> probing does want that
[20:31:26] <mhaberler> right
[20:31:46] <cradek> anything else?
[20:32:00] <mhaberler> a bottle of white?
[20:32:06] <cradek> I'd prefer the vpt machine not deal with variables at all if possible
[20:32:18] <cradek> if the probing report is the only thing, then it could be special
[20:32:46] <mhaberler> 'variables' or 'params' is a hodgepodge term
[20:32:53] <mhaberler> there are some which are user only
[20:33:06] <cradek> the vpt machine needs a readout that gets into the guis, you should be able to inspect its current position and feed rates etc
[20:33:07] <mhaberler> others reflect machine state
[20:33:33] <cradek> on the readout you can also inspect the last probed value and whether it succeeded etc, I guess
[20:33:38] <mhaberler> as I said: same machine - hal access; remote UI: halremote on steroids
[20:34:04] <mhaberler> and while we are at it, the state reporting parameters go the same route
[20:34:07] <cradek> so the ngc interpreter reads hal pins
[20:34:40] <mhaberler> sees hal state; in the local case it could but it wouldnt allow for a distributed interp/vtp setup
[20:35:10] <mhaberler> "seeing hal state" could be "accessing pins" or "asking the halremote layer"
[20:35:19] <cradek> I don't know what halremote is
[20:35:36] <mhaberler> it was a network interface to hal
[20:35:51] <mhaberler> it became defunct, I guess jepler recently deleted it
[20:36:04] <mhaberler> it wasnt usable in that form anyway
[20:36:10] <mhaberler> but the idea is string
[20:36:12] <mhaberler> strong
[20:37:04] <mhaberler> I would shoot for unifiying IPC with the HAL model as far as possible, this simplfies things a lot
[20:37:26] <mhaberler> wrt state inspection (aka the 'STAT' messages)
[20:37:36] <cradek> that stuff is above my pay grade
[20:37:38] <mhaberler> not for command queueuing
[20:38:12] <mhaberler> ok, assume you have some machine state which happens to be in shared memory. like emcmotstatus
[20:38:53] <mhaberler> now, assume all the fields in emcmotstatus have HAL names, because they have been mutated into pins
[20:39:19] <mhaberler> suddenly querying status becomes reading a HAL pin.
[20:39:51] <mhaberler> now for remote UI's all you need is a HAL reader, of which halremote was an early incantation
[20:40:42] <mhaberler> I'll cook up an example some day to convey the idea. not important right now.
[20:41:38] <cradek> ok, got it
[20:42:14] <mhaberler> the end of copying between status structs and pins (plus occasionally forgetting one, or injecting a race condition)
[20:42:29] <cradek> you know, it strikes me that the vpt language will have something like g40/g41/g42 and the desire to reread diameter at (at least) every g41/g42 becomes easy
[20:43:22] <cradek> I am a bit surprised that giving the vpt machine just the tool table seems both clean and like what we want/need
[20:43:45] <mhaberler> I'm not sure changing tooldia through a gladevcp slider is useful but it would make a great demo to see the preview impact
[20:44:15] <andypugh> Can we have a tool table not limited by NML size? And have multiple tools in one pocket?
[20:44:18] <cradek> it doesn't get us viewing ngc variables/ngc call stack during the run, which we also sometimes think we want
[20:44:23] <mhaberler> yes
[20:44:41] <andypugh> Sold
[20:44:43] <mhaberler> well there will be UI language local state
[20:45:00] -!- syyl_ws has quit [Quit: Verlassend]
[20:45:03] <cradek> yes but it's way ahead of execution like now
[20:45:28] <mhaberler> I am not sure vtp has any clue of a call stack; it might need a handle on the source context
[20:45:43] <mhaberler> the stack is a UI language issue, and must be tracked there
[20:45:44] <cradek> the vpt machine might have something like "active gcodes" but it won't be particularly familiar to the ngc user, and it'll not match the ngc readahead state
[20:46:15] <cradek> yes I still think the vpt machine wants a fancy N word of some kind
[20:46:22] <mhaberler> right.
[20:46:48] <cradek> hm, the fancy N word might contain arbitrary data that can be massaged into 'formerly active ngc codes'
[20:47:07] <cradek> hm, the fancy N word might contain arbitrary data that can be massaged into 'formerly active ngc codes and variables'
[20:47:38] <cradek> just a thought
[20:47:49] <mhaberler> we need to go through this settings/active codes stuff at some point, and see how that fits in
[20:47:51] <cradek> why couldn't the fancy N word be arbitrary stuff to display
[20:48:01] -!- fliebel has quit [Remote host closed the connection]
[20:48:10] <mhaberler> you mean a UI language execution state reference
[20:48:13] -!- micges [micges!~micges@dhp181.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[20:48:24] <cradek> yes
[20:48:43] <mhaberler> thats what ken meant with his gigantic log of _setup
[20:48:49] <cradek> the UI could hash its state and use the hash as the fancy N word
[20:49:02] -!- gambakufu has quit []
[20:49:18] <mhaberler> interesting idea
[20:49:38] <cradek> keep the UI data out of kernel space that way, and save lots of tape
[20:49:40] <mhaberler> so its a key to a historic UI language state
[20:49:47] <cradek> yes perhaps
[20:50:36] <mhaberler> that would be a great feature for users, going back in history
[20:51:03] <cradek> well I picture it as a way to show the real "current" (motion executing) state
[20:51:28] <mhaberler> plus the relevant UI language state I guess
[20:51:29] <cradek> users don't care much about readahead state and tape generation
[20:51:42] <mhaberler> for good reasons, I understand them
[20:51:45] <cradek> yes
[20:52:09] <andypugh> I guess we get rewind for free with this?
[20:52:19] <mhaberler> I'm about to fall over, but lets keep a laundry list: revisit the settings stuff and see how that fits in
[20:52:39] <cradek> ooooh, maybe on abort we can reclaim that state, and readahead becomes invisibile
[20:52:40] <mhaberler> rewind/roll forward would be worth exploring on the vtp code level
[20:53:10] <mhaberler> as it is now, yes - interplist dumped
[20:53:16] <andypugh> I note that Cradek has a vpt, and may has a vtp...
[20:53:19] <cradek> throw away tape, reclaim state
[20:53:30] <cradek> it's spelled vpt obviously :-)
[20:54:35] <cradek> yes the vpt program is going to be a LOT more invertable
[20:54:36] <andypugh> vpb == Virtuellenpapierband
[20:58:40] -!- DJ9DJ has quit [Quit: bye]
[20:59:33] <mhaberler> then, invertability requirements. I would assume that implies a state change record associated with a tape position, such that it can be undone (eg the offset change)
[21:00:12] <mhaberler> in database speak its the commit log
[21:00:14] <cradek> no, you don't want to put your old tool back in when you invert
[21:00:30] <cradek> I think you don't record that
[21:00:49] <cradek> you'd continue to use the current tool table data
[21:00:53] <mhaberler> I'm not saying that - I'd say on going back you'd like to know a) something changed b) what
[21:01:25] <cradek> maybe, but I'm not sure it's important
[21:01:36] <mhaberler> well hear ;)
[21:01:41] <mhaberler> we'll
[21:01:59] -!- sumpfralle has quit [Remote host closed the connection]
[21:04:09] <mhaberler> anyway, I'm crashing and will sleep over it. Great discussion btw; I think the next thing is to sketch it so it can be communicated, and search for the showstoppers
[21:04:33] <cradek> I agree
[21:04:46] <cradek> I'm feeling more optimism than despair about the design
[21:04:53] <mhaberler> wow
[21:04:55] <cradek> I bet it's a shocking amount of work, though
[21:05:10] <andypugh> Would you want to back up beyond a tool change? I can see it as an RFL, definitely, but that's a re-interp I think? I think it is fair to not allow reverse past a toolchange
[21:05:10] <cradek> there's sure despair about rewriting cutter comp :-/
[21:05:45] <andypugh> I think there are people willing to put in the work.
[21:06:10] <andypugh> Whether there are enough people, or the right people, I am less sure about.
[21:06:10] <cradek> I don't think we get arbitrary reversal automatically, but we could sure save up the tape somewhere
[21:06:53] <cradek> ... if we make the vpt language reversible (both endpoints specified, not just the target? is it that easy?)
[21:07:12] <mhaberler> yes?
[21:07:33] <cradek> and some way to tell the tape reader to reverse
[21:08:41] <mhaberler> no different than jog now: msgs from frontend, or pin wiggling
[21:09:01] -!- FinboySlick has quit [Quit: Leaving.]
[21:10:02] <cradek> bonus issue: why not implement world mode jogging in terms of vpt commands
[21:10:21] <cradek> and abort of course
[21:11:10] <cradek> I kind of don't know why we have a separate planner for jogging
[21:11:12] <mhaberler> another item on the laundry list is: task state model. Is jog-while pause something task should know about? replay?
[21:11:13] <cradek> (emc1 didn't)
[21:11:23] <mhaberler> I dont understand it either
[21:12:03] <cradek> maybe joint jogging can't be done with a vpt command, not sure, unless we can have the vpt machine swap to trivkins
[21:12:22] <mhaberler> if you have forward and reverse, it should work
[21:12:43] <cradek> I don't know what task should look like
[21:12:53] <cradek> ideally we'd start over
[21:13:12] <cradek> above my pay grade again :-)
[21:13:20] <mhaberler> I dont think the state distinctions make a lot of sense, in particular mdi versus auto
[21:13:37] <mhaberler> I have yet to understand the conceptual difference between a file and a string
[21:14:11] <cradek> well you can seek a file I guess, that's an important difference today but wasn't in emc1
[21:14:21] <andypugh> A file is used for removing metal manually. A string is used to hold your trousers up.
[21:14:29] <mhaberler> seek like for oword?
[21:14:32] <cradek> yes
[21:14:40] <mhaberler> thats history
[21:14:54] <mhaberler> (I hope, without looking at the bugtracker)
[21:15:02] <cradek> eh?
[21:15:45] <mhaberler> it is an arbitrary state distinction which originated from an interpreter restriction which is long since gone
[21:15:55] <andypugh> Hmm, just now on the forum. "I need to add a total on hour meter, I am using PyVCP, and classicladder.
[21:15:55] <andypugh> My question is how do I save and read the total hour on to a file."
[21:16:04] <cradek> I'm pretty excited by the thought of hashing ngc states for each ngc block, and restoring the right one on abort
[21:16:16] <mhaberler> gladevcp persistent state
[21:16:33] <andypugh> Aye, pity he is using PyVCP..
[21:16:41] <cradek> real hour meters are cheap
[21:16:48] <andypugh> Good point
[21:17:03] <mhaberler> in fact, yes
[21:17:35] <cradek> https://www.surpluscenter.com/item.asp?item=1-3593
[21:17:46] -!- micges has quit [Quit: Leaving]
[21:18:15] <cradek> how much of your time is worth $9.99 :-)
[21:18:59] <cradek> bbl again
[21:19:42] <mhaberler> now I know I will get heat for that, but: given the speed of todays databases, and the rollback capabilities, it would be worth revisiting whether UI language state can be mirrored in a database (mysql, postgres for instance)
[21:20:18] <andypugh> Are you still fond of Redis, or is that a different question
[21:20:50] <mhaberler> I think it is a good solution for late binding distributed state, it doesnt help with rollback
[21:21:22] <mhaberler> at leasnt not builtin, but thinking of it… it might help
[21:21:43] <mhaberler> I really need to nap over it, I learned that from jt
[21:22:18] <mhaberler> andy: I think it could be the cheapest solution with redis
[21:22:33] <andypugh> I have many of my best ideas asleep. It's annoying when you wake up and forget them.
[21:22:41] <mhaberler> ok, over and out. naptime. cu, folks - I really enjoyed it.
[21:22:46] <mhaberler> yeah, that sucks
[21:22:52] -!- mhaberler has quit [Quit: mhaberler]
[21:31:50] -!- Rogge has quit [Quit: Friends help you move. Real friends help you move bodies.]
[21:53:14] -!- JT-Shop has quit [Read error: Connection reset by peer]
[21:56:50] -!- sumpfralle has quit [Remote host closed the connection]
[21:57:13] -!- WalterN has quit [Read error: Connection reset by peer]
[21:58:31] -!- JT-Shop [JT-Shop!~John@184.20.140.167] has joined #linuxcnc-devel
[22:08:53] -!- i_tarzan has quit [Ping timeout: 248 seconds]
[23:05:58] -!- demacus_ has quit [Remote host closed the connection]
[23:24:34] -!- bedah has quit [Quit: bye]
[23:32:47] ybit is now known as mybitcoin
[23:36:03] -!- kb8wmc has quit [Quit: ChatZilla 0.9.88.2 [Firefox 11.0/20120310193829]]