#linuxcnc-devel | Logs for 2015-10-28

Back
[00:10:48] <ve7it> http://www.computerworld.com/article/2996526/security/joomla-patches-serious-sqli-flaw.html
[00:11:02] <ve7it> http://arstechnica.com/security/2015/10/joomla-bug-puts-millions-of-websites-at-risk-of-remote-takeover-hacks/
[07:13:45] <jthornton> will the 3.4-9-rtai-686-pae kernel work with LinuxMint?
[07:30:10] <jepler> jthornton: it looks like we have 3.4.9 as our kernel for ubuntu precise and debian wheezy. if it's the 32 bit version and linux mint is based on one of those OSes then it's likely to work ; if not, it's less likely to
[07:37:23] <jthornton> according to wikipedia "Linux Mint is a Linux distribution based on Debian and Ubuntu,[4] with an alternative Linux Mint Debian Edition (LMDE) based purely on Debian"
[07:54:42] <jepler> right
[07:55:17] <jepler> but which version of debian or ubuntu? If it's one newer than precise or wheezy, then our kernel is less likely to work
[07:56:01] <jepler> but the user is welcome to try it and should be able to boot back into their old kernel without issue if it doesn't work
[07:56:06] <jepler> via the grub menu
[07:56:09] <jepler> afk
[08:06:36] <jthornton> I might give it a try later just to see what it is
[08:07:53] <jthornton> found some info on what version it is based on http://www.linuxmint.com/oldreleases.php
[08:32:01] <seb_kuzminsky> my guess is it will work
[08:32:20] <seb_kuzminsky> our lucid rtai kernel worked with the precise userspace way back when
[08:32:25] <JT-Shop2> linux mint 13 is based on precise
[14:01:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05zultron/remap-startline-fix 4a148a8 06linuxcnc 10src/emc/motion-logger/motion-logger.c motion-logger: fix mock of SET_POSITION_LIMITS * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4a148a8
[14:01:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05zultron/remap-startline-fix 0678cbe 06linuxcnc 10(10 files in 2 dirs) tests: add a motion-logger test of a possible remap bug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0678cbe
[14:01:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05zultron/remap-startline-fix a18b4af 06linuxcnc 10tests/motion-logger/mountaindew/checkresult mountaindew test: verify the result in the right directory * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a18b4af
[14:02:01] <KGB-linuxcnc> 03John Morris 05zultron/remap-startline-fix 08dce7b 06linuxcnc 10tests/motion-logger/mountaindew/expected.motion-logger 10tests/motion-logger/mountaindew/test-ui.py Fix mountaindew test * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=08dce7b
[14:02:06] <KGB-linuxcnc> 03John Morris 05zultron/remap-startline-fix cc4caac 06linuxcnc 10src/emc/task/emctaskmain.cc Bugfix: Start line and remap interaction * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cc4caac
[14:18:56] <KGB-linuxcnc> 03John Morris 05zultron/remap-startline-fix b714b53 06linuxcnc 10src/emc/task/emctaskmain.cc Bugfix: Start line and remap interaction * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b714b53
[15:53:37] <mozmck> Looking at the markdown sample on wikipedia - to me it seems more cryptic than html overall
[15:54:36] <jepler> markdown, asciidock, wiki markup all make the simple things easy and the complex things very very hard
[15:54:41] <mozmck> I like the list indicators, and links, but two spaces for a line break?
[15:54:52] <mozmck> heh!
[15:56:11] <jepler> I did not know this thing about the function of two trailing spaces on a line. significant trailing whitespace has got to be worse than significant leading whitespace since it's much less visible
[15:56:45] <mozmck> seems so to me.
[16:00:30] <jepler> in github flavored markdown as implemented at http://tmpvar.com/markdown.html you can put <br> on its own line instead of two-trailing-spaces
[16:00:38] <jepler> .. but not on the other one of two markdown previewers I tried
[16:01:40] <seb_kuzminsky> i'm looking at jekyll for the generation of static html from git, as a replacement for joomla for wlo
[16:01:49] <seb_kuzminsky> it uses markdown by default
[16:02:47] <jepler> I jused jekyll for a short time. I got stuck when it came to adding lightbox-style photo albums to my site because I would have had to go deeper than just writing markdown
[16:03:00] <mozmck> seb_kuzminsky: yes, that's why I was looking at markdown.
[16:03:33] <mozmck> So far I'm not sure what markdown would give you that you can't do just as easily in html?
[16:04:22] <jepler> it's back to that "makes simple things easy" point
[16:04:38] <jepler> typing 99% text is better in a lot of ways than typing 50% markup
[16:06:57] <mozmck> true. The sample here: https://en.wikipedia.org/wiki/Markdown shows markdown to but not much less text than html, but that may not be typical.
[16:07:08] <seb_kuzminsky> i think it helps you to have consisted css, headers & footers and that kind of thing
[16:07:11] <seb_kuzminsky> maybe
[16:07:16] * seb_kuzminsky <-- not a webmaster
[16:07:59] <jepler> mozmck: compare https://github.com/jepler/dashing/blob/master/README.md vs its raw text version https://raw.githubusercontent.com/jepler/dashing/master/README.md
[16:08:57] <jepler> which reminds me I changed the API and didn't change README.md
[16:10:01] <mozmck> Not bad
[16:18:20] <jepler> that was a fun little project too
[16:20:15] <seb_kuzminsky> looks cool
[16:20:21] <seb_kuzminsky> was it for the laser?
[16:20:29] <jepler> no but it should be!
[16:21:24] <seb_kuzminsky> jekyll appealed to me because it's widely used, mostly (it's what github pages uses)
[16:21:44] <seb_kuzminsky> there's also one called pelican, which is less widely used but writtne in python, which appeals to me
[16:22:01] <jepler> yes, the wide adoption (among all static page generators) is certainly a big mark in its favor
[16:22:11] <seb_kuzminsky> (there was also the crazy, crazy thought of just using asciidoc, like we do for our product docs, but i think that's crazy)
[16:23:14] <jepler> more like we should convert our docs to markdown because then the "I don't know how to asciidoc" factor goes away: you can use the not-quite-live preview right on github to make your change and prepare your pull request
[16:24:02] <jepler> "I don't know how to asciidoc" and "I don't know how to git" in one swell foop, if we don't mind assuming that anyone can use a website without learning it
[16:24:07] <seb_kuzminsky> asciidoc isnt that different from md, is it? the live preview on github (or locally, with "jekyll serve --watch") is pretty nice i agree
[16:24:44] <seb_kuzminsky> they'd still have to git, or does github have some kind of horrible editor-in-a-webpage thingy? with a commit button?
[16:24:50] <jepler> seb_kuzminsky: right
[16:25:14] <jepler> go to a README.md in your fork of some repo, and click the "pencil" icon at the top left
[16:25:23] <jepler> I actually just edited dashing/README.md that way
[16:25:31] <seb_kuzminsky> ermagerd
[16:25:38] <jepler> when your'e done you click a button and get a pull request
[16:25:51] <jepler> you're
[16:25:52] <seb_kuzminsky> the future is now
[16:26:06] <jepler> but you can also click over to an almost-live preview which shows deletions and additions too
[16:27:14] <seb_kuzminsky> yeah, i see it. neat!
[16:28:27] <jepler> live preview or wysiwyg would be a tad better, but compared to saying "get the whole asciidoc toolchain, learn to compile and make and manually load the result in your browser or pdf viewer" it's really slick
[16:28:36] <jepler> except our docs are in asciidoc, not markdown
[16:28:43] <jepler> asciidown, markdoc, etc
[16:30:41] <jepler> but maybe we could get from here to there with asciidoc -> [some input format of pandoc such as docbook] -> markdown
[16:30:51] <jepler> buuuut I really don't want to bite off that unchweable mess right now
[16:33:29] <seb_kuzminsky> yeah
[16:33:33] <seb_kuzminsky> babysteps
[16:33:50] <mozmck> There is also something called gitbook
[16:34:11] <mozmck> https://www.gitbook.com/
[16:34:20] <jepler> also a part of me would feel bad for choosing a doc format just because it works well with a proprietary service :-/
[16:35:01] <mozmck> gitbook sounds similar to what you are talking about jepler
[16:35:11] <KGB-linuxcnc> 03John Morris 05zultron/m98m99 26e3f93 06linuxcnc 10(43 files in 11 dirs) Fanuc-style m98/m99 subroutines * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=26e3f93
[16:35:18] <mozmck> but it handles asciidoc format too
[16:37:28] <mozmck> seb_kuzminsky: apparently there are several static site generators: https://www.staticgen.com/
[16:37:33] <seb_kuzminsky> zultron is on fire lately
[16:37:43] <seb_kuzminsky> mozmck: yeah there's tons
[16:37:56] <seb_kuzminsky> an embarrassment of riches
[16:38:10] <skunkworks> oh - it is there..
[16:38:22] <skunkworks> that is pretty awesome
[16:40:03] <seb_kuzminsky> gitbook might be appropriate for our docs, but it doesn't look right for the website (which is the main thing i'm thinking about right now)
[16:40:44] <seb_kuzminsky> i wonder what the staticgen.com website uses
[16:40:57] <seb_kuzminsky> oh, Middleman
[16:41:37] <mozmck> yes, I was just thinking it sounded like what jepler was talking about for docs.
[16:42:47] <seb_kuzminsky> sure
[16:43:16] <seb_kuzminsky> on the topic of docs, the main thing i dont like about asciidoc is that we have not yet figured out how to do inline math equations
[16:44:26] <mozmck> I wonder how gitbook handles that - they say they fully support TeX/Math equations
[16:45:30] <JT-Shop> there is asciidoctor now, I'm not sure what it has over asciidoc except that you can make a link open in a new page
[16:45:57] <andypugh> The hm2_7i90 manpage says that one must use “loadrt epp” to load the parport driver, but if I do that I get an error: “can’t finf module epp”
[16:46:12] <andypugh> Well, except it is spelled correctly
[16:47:14] <mozmck> kicad recently switched from confluence (java <barf>) to hugo
[16:47:43] <mozmck> http://kicad-pcb.org/ and http://gohugo.io/
[16:48:26] <seb_kuzminsky> andypugh: i think i had intended to move the duplicated epp code in 7i43 and 7i90 out to a separate module, but never got around to it :-/
[16:48:54] <jepler> I don't know what that paragraph is intended to refer to
[16:49:41] <jepler> I think the paragraph should simply be removed, and from 7i43's manual page if it is there too
[16:50:17] <seb_kuzminsky> agreed
[16:50:43] <andypugh> Was the plan ever for a generic hm2_epp or are the cards too different?
[16:50:57] <jepler> the cards are quite similar and a generic driver should be very possible
[16:51:41] <seb_kuzminsky> the 7i90 driver was added in 2.6, the manpage should be fixed there
[16:53:06] <seb_kuzminsky> a unified driver was tricker than i first thought, for some reason
[16:53:13] <seb_kuzminsky> the 7i90 always has firmware, so it's easy to probe for
[16:53:29] <seb_kuzminsky> the 7i43 has no firmware between power-on and firmware-loading, so it can't really be probed for
[16:53:39] <seb_kuzminsky> the best you can do it try to flash it and see if it worked
[16:53:46] <jepler> are you sure about that?
[16:54:12] <seb_kuzminsky> i think each of those statements is true
[16:54:44] <jepler> http://www.mesanet.com/pdf/parallel/7i43man.pdf says there are two EPP registers available before the FPGA is configured
[16:54:52] <jepler> and one of them can be used to "verify fpga size"
[16:54:52] <andypugh> I guess that settting it up so that it assumes 7i43 if there is a “firmware=“ entry is asking for trouble.
[16:55:12] <seb_kuzminsky> jepler: hrm, right, the cpld
[16:55:52] <seb_kuzminsky> it's not a very good probe - you read a byte and if it's ones it might mean you have one of the size of fpga, and if its zeroes it might mean its the other size fpga
[16:56:11] <seb_kuzminsky> or it might mean there's nothing connected, and your parport inputs are pulled high or low
[16:56:18] <andypugh> I seem to recall that if your 7i43 is missing you get told it is too small, so it may be that one of those registers returns the same thing for a small FPGA and no FPGA.
[16:56:19] <jepler> then you'd get an epp failure
[16:56:20] <seb_kuzminsky> or it's some other device
[16:56:43] <jepler> or we could require that the combined driver use the EEPROM configuration method
[16:56:54] <jepler> the 7i43 does have a configuration EEPROM, not sure if mesaflash supports it though
[16:58:26] <micges> iirc 7i43 firmwares doesn't have access to eeprom like 7i90
[16:58:31] <seb_kuzminsky> i like it on the rare occasions when we build new hm2 firmware debs that i dont have to remember to do anything, and i get the new firmwares next time i launch linuxcnc automatically
[16:58:40] <micges> it could be done but noone asked for it yet
[16:58:46] <jepler> micges: OK, thanks for the info
[16:59:07] <andypugh> It seems like rather a lot of trouble to make hm2_* very slightly tidier.
[16:59:41] <andypugh> (though hm2_7i90 might come back to haunt you if PCW develops any more EPP cards)
[17:00:08] <jepler> more likely, if there *ever* a new EPP board, and presuming it has a configuration EEPROM that works like all other recent boards, the hm2_7i90 driver should become the generic hm2_epp but 7i43 would still require the old driver
[17:01:08] <seb_kuzminsky> bbl
[17:01:09] <jepler> hypothetical detection algorithm: set address 01 00; epp read 4 bytes
[17:01:17] <jepler> if you get 55AACAFE you have a preconfigured board
[17:01:25] <jepler> if you get 00000000 you have on size 7i43
[17:01:30] <jepler> and if you get 01010101 you have the other size
[17:01:32] <seb_kuzminsky> i'm going to futz with jekyll, unless anyone hates it on sight
[17:01:45] <jepler> if you have any other value or an epp communication error, you bail
[17:02:32] <PCW> I _think_ it does
[17:02:40] <andypugh> I am trying to work out why we would want Fanuc-style subroutines.
[17:02:51] <PCW> (mesaflash support 7I43 EEPROM)
[17:03:42] <PCW> the 7I43 driver will fail with EEPROM loaded 7I43s also
[17:04:29] <micges> PCW: iirc 7i43 eeprom access is by special firmware?
[17:04:49] <PCW> (this is why it fails with 7I90s it resets the card (losing EPP access)
[18:18:55] <skunkworks> andypugh: to make gcode more compatable with mach.. :)
[18:20:42] <Tom_itx> oh fooey
[18:20:43] <skunkworks> oh - and fanuc. ;)
[18:22:17] <skunkworks> like http://www.cnczone.com/forums/tormach-personal-cnc-mill/285732-share-sub-routines.html#post1780218
[18:22:35] <skunkworks> but that guy has 'never had an issue with mach3..' ever
[18:27:34] <cradek> andypugh: people have asked for it more than a few times
[18:54:36] <andypugh> I thought that Mach used O-words too
[18:55:06] <andypugh> I doubt that many post-processors use subs in Fanuc-posted code
[20:23:51] <skunkworks> I think m98/99 are pretty popular. I know i used the when I used to run a laser years ago
[20:24:02] <skunkworks> on a fanuc control
[20:25:38] <jepler> hm, I wonder what I'm doing wrong. driving a servo motor connected to 4i30, the motor only goes one way
[20:26:04] <jepler> I verified that the pwm_value_reg looks plausible, it gets the sign bit set when negative
[20:26:09] <jepler> sets cmd -20
[20:26:09] <jepler> halcmd: pwm_value_reg -> 83330000
[20:26:12] <jepler> halcmd: sets cmd 20
[20:26:12] <jepler> halcmd: pwm_value_reg -> 03330000
[20:27:00] <jepler> output-type is 1
[20:31:53] <jepler> gpio 009 "direction" seems to change appropriately
[20:32:09] <jepler> it's running open-loop so it's not PID or something
[20:32:25] <jepler> er 7i30 of course
[20:32:47] <andypugh> I was looking at the 4i30 and wondering what you were doing with LinuxCNC and PC104
[20:34:04] <andypugh> jepler: It isn’t a field-coil motor?
[20:35:40] <jepler> it's a pittman servo, same one that I had on the zenbot last time it ran (with a 7i30) years ago
[20:36:48] <andypugh> Is 7i30 an up/down pwm device?
[20:36:54] <jepler> no, pwm & direction
[20:37:43] <jepler> (7i30man page 4)
[20:38:52] <jepler> the old hal files I have never set output-type away from the default, which is documented to be type 1
[20:39:16] <jepler> it *could* be some ARM-specific bug
[20:39:34] <jepler> .. but I used odroid u3 + 7i90-spi + 7i30 last year at txrx labs
[20:49:32] <jepler> or it could be a cabling problem, though I measure a sensible (<5ohm) winding resistance, and about the same resistance from each winding to ground when the amplifier is unpowered. (it had occurred to me that "one end of widing shorted to ground" could get me unidirectional motion)
[20:51:01] <andypugh> windings to gnd sounds wrong, actually
[20:51:45] <jepler> it's not a low resistance, 15kohm
[20:53:30] <jepler> second motor on second pwmgen has the same behavior
[20:54:46] <andypugh> I assume that a multimeter shows that the output isn’t changing polarity?
[20:55:15] <jepler> should it be OK to meter voltage while it's running?
[20:55:31] <jepler> do I want to meter voltage across the windings?
[20:55:51] <andypugh> I don’t see why not, multimeters are very high impdeance
[20:57:21] <jepler> it meters +1.9v for pwmgen.01.value .1 and -.1, 0v for value 0
[20:58:12] <andypugh> -0.1V ?
[20:58:39] <jepler> pwmgen.01.value .1 -> voltage across windings = +1.9v
[20:58:41] <andypugh> And what for pwmgen.01.value -1 ?
[20:58:41] <jepler> pwmgen.01.value -.1 -> voltage across windings = +1.9v
[20:58:48] <jepler> pwmgen.01.value 0 -> voltage across windings = 0v
[20:59:54] <andypugh> And you say that you can see the DIR pin value change?
[21:00:11] <jepler> according to halcmd looking at that GPIO as an input
[21:00:53] <andypugh> Might be worth checking with the multimeter at the 7i30 end of the cable
[21:02:30] <PCW> cable 5V OK at 7I30?
[21:02:57] <jepler> I'll check
[21:03:32] <jepler> ugh no, about 4.3v
[21:03:35] <andypugh> How has Gene found it possible to make the G-code for a comb-joint expand to use all his memory?
[21:03:59] <jepler> ok, I'll fix my 5v supply and try again
[21:07:14] <PCW> Gene finds lots of bugs
[21:08:22] <PCW> I was surprised by the pncconf localization bug in the forum (pncconf doesnt work in italian)
[21:09:09] <andypugh> Hmm, I may not have needed the 7i73, the 7i84 MPG inputs might have been enough. Though perhaps they will be handy for spindle/feed oveeride
[21:09:37] <andypugh> Yes, that was a fun one. I wonder if it was a string comparision somewhere?
[21:10:27] <andypugh> cradek: seb_kuzminsky: Do any of the tests run in a different locale?
[21:10:39] <cradek> doubt it
[21:11:04] <andypugh> A proper pedant would do that
[21:11:38] <cradek> especially one that uses , for decimal point
[21:11:54] <PCW> another formum post point to a possible hostmot2 driver bug
[21:12:26] <andypugh> The British Standard for technical drawings says to use a comma. And Autodesk Inventor is happy with that format in sketches
[21:16:49] <jepler> good 5v at the 7i30 now, no change in behavior
[21:18:08] <PCW> I don't think Ive see a 7I30 bridge chip fail that way (only drives one way regardless of direction)
[21:19:12] <jepler> let alone two at once
[21:19:14] <PCW> Maybe check the direction signal voltage at the 7I30
[21:22:13] <jepler> any good spots to probe it? pull cable and probe at end of cable?
[21:22:41] <PCW> Strangely enough Eastman Kodak has been buying a trickle of 7I30s from us for almost 10 years
[21:23:17] <PCW> back of card on 50 pin connector probably
[21:24:42] <PCW> count odd pins from 1 (DIR0 is 19)
[21:25:05] <jepler> on 7i90, W6 is up and W1 is up
[21:25:39] <jepler> looks sensible
[21:25:42] <PCW> That sounds right
[21:25:44] <PCW> bbl SO paging _loudly_
[21:35:34] <mozmck> nameless hal signals would be nice
[21:44:14] <jepler> mozmck: seems like I had prepared a patch for that sometime in the past
[21:45:05] <mozmck> I remember smelling a whiff of something like that a while back.
[21:45:58] <jepler> I can't find it right away
[21:46:39] <mozmck> it's obviously not critical, but it might help de-clutter the HAL namespace
[21:47:34] <mozmck> I would presume something like that could be done by internally assigning a unique name at runtime?
[21:47:52] <jepler> yeah
[21:48:00] <jepler> it would not prevent the thing from showing up in 'halcmd show sig' either
[21:48:23] <jepler> linuxcnc-devel-2014-08-17.log:10:55 < KGB-linuxcnc> Jeff Epler jepler/anonymous-net 51476c5 linuxcnc src/hal/utils/halcmd.c src/hal/utils/halcmd_commands.c src/hal/utils/halcmd_commands.h src/hal/utils/halcmd_completion.c halcmd: allow net command to create anonymous nets * http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=51476c5
[21:48:39] <jepler> looks like the branch is still out there on glo
[21:48:58] <mozmck> ooh, I'll take a look - or put it on my list to do. thanks!
[21:49:32] <jepler> I think the 7i90 may be damaged
[21:50:51] <jepler> with linuxcnc stopped, most pins measure +5v by multimeter, but pin 19 measures 2.5v, vcc/2
[21:51:20] <jepler> pins 21 and 23 measure 0v, then back to 5v
[21:51:54] <jepler> ... this *is* the card that was connected to the 7i30 we blew up in texas
[21:52:04] <jepler> at the time we didn't think it was damaged by the event but maybe it was
[21:53:29] <mozmck> 2.5v sounds bad, I presume it doesn't toggle when you change dir?
[22:02:32] <jepler> time to call it a night