Back
[10:26:31] <seb_kuzminsky> wow, it's sure easy to make asciidoc emit super ugly html anchors (like the one kwallace linked above)
[10:27:18] <seb_kuzminsky> i think now that we check all the links on our html docs at build-time, making explicit, unchanging anchor names is no longer useful
[10:27:49] <seb_kuzminsky> we should just use the default anchor names that asciidoc makes automatically from the section names
[10:28:09] <seb_kuzminsky> if we change a section name and forget to update the places that linked to the old section name, the build system will tell us
[10:34:53] <seb_kuzminsky> here's what i mean:
http://pastie.org/10264536
[10:35:13] <seb_kuzminsky> that changes the link name from this: docs/html/remap/structure.html#_the_em_argspec_em_parameter_a_id_remap_argspec_parameter_a
[10:35:26] <seb_kuzminsky> to this: docs/html/remap/structure.html#_the_argspec_parameter
[10:44:51] <archivist> non changing anchor names are very useful for persistent links on the net
[10:46:40] <seb_kuzminsky> good point
[10:47:09] <seb_kuzminsky> for links from external documents that are not under our control
[10:49:47] <kwallace> What did I do?
[10:49:48] <seb_kuzminsky> we could have some policy like "no changing anchor names in a stable branch", like an externally visible api
[11:05:20] <JT-Shop> did you delete the anchor in that example?
[11:06:08] <seb_kuzminsky> kwallace: you posted a link to our docs that demonstrated how poorly asciidoc generates html fragment anchors
[11:07:07] <seb_kuzminsky> JT-Shop: yes, i removed the explicit anchor (lines 35-37 in the paste of the diff), which causes asciidoc to generate its own anchor from the section title
[11:07:32] <seb_kuzminsky> and i changed all the links to that section to use the new auto-generated anchor name instead (all the rest of the paste)
[11:08:27] <seb_kuzminsky> it makes the asciidoc source a little simpler, and it makes the URL much simpler
[11:09:11] <archivist> but random manual to manual?
[11:10:50] <JT-Shop> so we don't need any anchors anymore so long as the links are properly structured?
[11:13:13] <JT-Shop> does the link have to match the section exactly including case?
[11:13:56] <JT-Shop> well looking at the example I'd say case is not a factor
[11:21:06] <jepler> the anchor part of a URL is case sensitive.
http://www.w3.org/TR/html401/struct/links.html#h-12.2.1
[11:21:28] <jepler> Anchor names must observe the following rules:
[11:21:28] <jepler> Uniqueness: Anchor names must be unique within a document. Anchor names that differ only in case may not appear in the same document.
[11:21:31] <jepler> String matching: Comparisons between fragment identifiers and anchor names must be done by exact (case-sensitive) match.
[11:22:09] <jepler> and also
[11:22:10] <jepler> Anchor names should be restricted to ASCII characters.
[11:32:11] <JT-Shop> zlog
[11:37:58] <mozmck> Hmm, is there a way to make Gremlin not show G92 offsets in the toolpath?
[11:38:56] <cradek> do you mean not show the G92 offset line and label?
[11:39:35] <cradek> pretty sure those lines and labels are an option in AXIS
[11:40:21] <mozmck> No, in the view of the program. In a cut program I do a G38.2 Z-0.37 F20.0 probe and then I do G92 Z0.0
[11:40:53] <mozmck> This is done often to re-set the Z position based on the material warping as you plasma cut it.
[11:41:52] <mozmck> In Gremlin when you load the program it shows each piece where you do the G92 at a higher Z location. This is a custom GUI using Gremlin.
[11:46:32] <jepler> no, that's not an existing facility in gremlin or axis.
[11:48:03] <mozmck> ok, thanks.
[11:54:11] <mozmck> Here's what it looks like, but it should be flat:
http://pasteboard.co/1AvIYcNa.png
[11:54:47] <mozmck> Any thoughts on how to make it look right?
[11:55:00] <cradek> in general, you can't correctly preview a program with probing in it
[11:55:10] <mozmck> hmm...
[12:20:48] <seb_kuzminsky> JT-Shop: here's how asciidoc generates section ids (which become html anchors) from section titles:
http://www.methods.co.nz/asciidoc/userguide.html#_section_ids
[12:43:37] <jthornton> mozmck, I just view my plasma from the Z end so I don't see all the probe moves
[12:48:18] <jthornton> seb_kuzminsky, thanks for the link... I was working on the anchors on 2.7 but I'll switch gears now
[13:00:49] <mozmck> jthornton: that's what I was thinking would be a quick fix. Is there a way to restrict the view to the Z end?
[13:01:45] <jthornton> I don't know of a way to do that, might look at how the lathe view works for axis for clues
[13:28:53] <kwallace> Let's say I'm writing a .py file to make a new g-code. It seems I could use import linuxcnc then use linuxcnc.status, poll and a keyword to get a parameter, or I could forgo any imports and get the parameter directly with self.parameter[what_I_need]. How would I choose one method over the other?
[13:33:24] <jepler> I would not use linuxcnc.status.
[13:35:44] <kwallace> Hmm, okay.
[13:36:03] <jepler> linuxcnc.status reflects task's idea of what is going on in the interpreter
[13:36:12] <jepler> that view is not necessarily up to date
[13:36:26] <jepler> and if you are, say, creating a preview plot within axis/gremlin, then task's state is *not even relevant*
[13:37:13] <jepler> say you need to do something based on the loaded tool. self.params['_current_tool'] will reflect that your part program already did T1M6
[13:37:46] <jepler> .. but linuxcnc.status tool_in_spindle is not going to reflect that, it reflects what's actually in the spindle
[13:40:55] <kwallace> Thank you, it'll may take a while to digest this.
[15:16:46] <mozmck> pcw_home: seems like you mentioned testing hm2-eth on a laptop?
[15:48:20] <PCW> mozmck: yes:
[15:48:21] <PCW> freeby.mesanet.com/e6420.png
[15:48:23] <PCW> freeby.mesanet.com/linuxcnc.png
[15:49:36] <PCW> Dell e6420 with dual core second gen I5 at 2.5 GHz
[16:07:24] <PCW> runs fine as long as you dont change from line power to battery or vice versa when linuxcnc is running
[16:20:38] <KGB-linuxcnc> 03Moses McKnight 052.7 176c958 06linuxcnc 10lib/python/gladevcp/hal_actions.py EMC_ToggleAction_Run needed extra check on file load. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=176c958
[16:21:06] <mozmck> PCW: ok, thanks.
[16:25:18] <PCW> I stole power fro the 7I92 from a USB port
[16:55:29] <skunkworks> zlog
[17:17:11] <mozmck> In the docs here
http://www.linuxcnc.org/docs/2.7/html/config/ini_config.html#_traj_section it says using NO_FORCE_HOMING = 1 will allow the machine to go beyond the soft limits while in operation, but I still get an error about exceeding the limit on an axis and linuxcnc stops running the code.
[17:17:22] <mozmck> So are the docs wrong, or is this a bug?
[17:20:07] <cradek> that warning is probably imprecise
[17:20:28] <cradek> the author probably meant that you can't trust linuxcnc to know where your travel ends if you don't home
[17:20:56] <cradek> I'm not surprised you get bogus ends of travel in incorrect locations
[17:21:01] <PCW> so _more_ likely to get soft limit errors
[17:21:31] <cradek> yes it might be that you have the same working volume, but it's in an unknown location
[17:21:50] <cradek> why do you want to run gcode without being homed?
[17:25:59] <mozmck> because some machines don't even have home switches :)
[17:26:12] <cradek> you should still home them
[17:26:18] <mozmck> how?
[17:26:20] <JT-Shop> yep that's what I meant to say
[17:26:26] <cradek> mark a known location, jog to it, hit home
[17:26:31] <JT-Shop> match marks
[17:26:43] <cradek> then it's super easy if before you shut down you move it back there
[17:27:05] <JT-Shop> after you home you can do a G53 G0 X0 Y0 Z0
[17:27:07] <cradek> if you have servos with encoders, you can use home to index (only)
[17:27:24] <JT-Shop> I have a pyvcp button that runs the above in mdi
[17:27:32] <cradek> index-only will give you perfect repeatibility
[17:27:41] <mozmck> So for something like that I can just not define any HOME*VEL settings in the inifile?
[17:27:43] <cradek> home to marks without index will give you soft limit protection
[17:27:59] <cradek> iirc, you set them to zero, check the homing doc
[17:29:54] <mozmck> Ok, I see.
[17:30:22] <mozmck> So why should you home the machine? Just for soft-limits?
[17:30:56] <JT-Shop> yea
[17:31:00] <mozmck> ok
[17:46:18] <KGB-linuxcnc> 03John Thornton 052.6 ecd7520 06linuxcnc 10docs/src/config/ini_config.txt Docs: restate warning to be more precise * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ecd7520
[20:16:39] <jepler> seb_kuzminsky: I wonder if you'd review origin/jepler/hm2-eth-simplify for 2.7. it's tested by mozmck, though I reworked it slightly since the version he tested
[23:58:15] <seb_kuzminsky> jepler: does this mean linuxcnc (at least in uspace configuration) should depend on iptables?
[23:58:34] <seb_kuzminsky> it feels like there should be a libiptables that would let you do all the things hm2_eth does via the shell
[23:58:46] <seb_kuzminsky> (not that it's worth converting to using the library at this point)
