Back
[07:41:50] <jepler> www.nytimes.com/2015/10/08/business/dealbook/dell-is-said-to-be-in-talks-to-acquire-emc.html
[07:41:55] <jepler> boy I'm glad I know they don't mean us :-P
[07:49:02] <skunkworks> good thing we changed our name...
[07:53:53] <skunkworks> http://www.cnczone.com/forums/tormach-personal-cnc-mill/278462-tormach-21.html#post1771976
[08:09:25] <jepler> sigh
[08:10:22] <jepler> I am getting less and less excited about ensuring that liblinuxcncui can be used in non-Free software.
[08:10:29] <jepler> I would rather ensure that the UI has to be GPL
[08:17:29] <skunkworks> I bet
[08:22:23] <skunkworks> Well - I think I found the phone that will last me a few years. (until I drop it) gallaxy s5. Rooted and cleaned.
[08:23:01] <skunkworks> decent picutures and fast enough.
[08:23:16] <ssi> gpl can be a hassle that way :/
[08:50:02] <cradek> jepler: allowing easy mixing with nonfree software is absolutely not a goal of mine
[08:50:14] <cradek> jepler: (not that I've done any of the lui work)
[08:52:37] <malcom2073> Heh, Umbutu (Ubuntu) and Deneil (Debian)
[09:01:33] <seb_kuzminsky> jepler: i think it was i that originally argued for lgpl for lui, but i no longer feel strongly for that
[09:37:17] <pcw_home> " I want the stepgens on 7i92 "p1"
[09:37:19] <pcw_home> There are often xxxxR.bit firmware images that swap the connectors
[09:39:07] <pcw_home> ISTR the idea of having bit masks was discussed when hm2 was first written but
[09:39:08] <pcw_home> discarded as too complex for the user
[09:39:38] <pcw_home> maybe stepgens= "1,3,6"
[09:40:15] <jepler> that would probably be better for a user
[09:46:34] <jepler> hm, I started investigating "Jullian"'s question about arc normals because having z=<1 mm in inches> seemed wrong
[09:47:05] <jepler> but the print I added in taskintf.cc:emcTrajCircularMove shows the normal as always zero
[09:48:39] <cradek> circularMoveMsg.normal = to_ext_len(normal_cart);
[09:50:04] <jepler> normal = 0.000000 0.000000 1.000000
[09:50:04] <jepler> normal = 0.000000 1.000000 0.000000
[09:50:04] <jepler> normal = 1.000000 0.000000 0.000000
[09:50:19] <cradek> I wonder how he was printing the debug output
[09:50:41] <jepler> too bad the e-mail doesn't say
[09:50:41] <cradek> I wonder if he saw a bug and that led him here
[09:50:50] <jepler> too bad the e-mail doesn't say
[09:51:17] <jepler> so yes it's nonzero for me in ARC_FEED
[09:51:42] <jepler> but zero by the time it gets to emcTrajCircularMove!
[09:51:47] <cradek> Issuing EMC_TRAJ_CIRCULAR_MOVE -- ( +221,+184, +0,0.000000,1.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.039370, +0, +3,1.650000,5.000000,50.000000, +0,)
[09:53:01] <cradek> I agree this is surprising
[09:53:46] <jepler> oh %.1f
[09:53:52] <jepler> .039 of course prints as 0.0
[09:53:56] <jepler> nevermind
[09:54:07] <jepler> 1275 fprintf(stderr, "normal = %.1f %.1f %.1f\n", normal.x, normal.y, normal.z);
[09:54:11] <jepler> that's the line I had added
[09:55:43] <cradek> basic testing of arc planes looks right to me
[09:58:19] <jepler> I ran 3dtest with a rotation in my coordinate system and I down at emcTrajCircularMove I saw non-axis-aligned normal vectors
[09:58:23] <jepler> normal = 0.000 0.000 0.039
[09:58:23] <jepler> normal = -0.021 0.033 0.000
[09:58:23] <jepler> normal = 0.033 0.021 0.000
[09:58:28] <jepler> so, yeah, seems like it is OK
[09:58:33] <seb_kuzminsky> yay
[09:58:39] <jepler> except that the silly conversion from mm to in should be fixed
[10:44:15] <cradek> fwiw, 2.6 prints the vector as 0,0,1
[10:45:01] <cradek> [2.6] circularMoveMsg.normal = normal;
[10:50:46] <cradek> - circularMoveMsg.normal = normal;
[10:50:50] <cradek> + circularMoveMsg.normal = to_ext_len(normal_cart);
[10:50:59] <cradek> "Bulk overhaul of emccanon"
[10:52:16] <seb_kuzminsky> heh, that's the commit that introduced that ABCUVW arc bug i recently fixed, too
[10:52:52] <seb_kuzminsky> we should add a pre-receive hook that rejects any commit message containing "bulk" or "overhaul", that'll fix the problem for sure
[10:53:29] <cradek> well I have feels about refactoring, but all we can really do is clean up the new bugs afterward
[10:55:20] <cradek> after you're done with that step, it's true that the code often looks better
[10:57:54] <cradek> the only/ultimate self defense is better test coverage
[10:58:08] <seb_kuzminsky> and it may be more maintainable, as a result of being easier to read. i think there's a place for refactoring in code maintenance.
[10:58:18] <archivist> it is the syndrome that you cannot see a bug until you refactor, accidently adding a few more while you do it
[10:58:40] <seb_kuzminsky> and i agree test coverage is important when refactoring :-)
[10:58:42] <cradek> I really wonder why our tests didn't notice this particular one
[10:59:25] <cradek> ... because sai doesn't print the normal vector
[10:59:28] <seb_kuzminsky> does the length of the normal matter? isn't it just the direction that's important?
[10:59:44] <cradek> N..... ARC_FEED(99.7764, 97.8882, 100.0000, 98.0000, -1, 0.0000, 0.0000, 0.0000, 0.0000)
[11:00:13] <seb_kuzminsky> sai also doesn't print UVW, which would have caught the previous bug in that commit
[11:00:38] <cradek> it could conceivably matter if it's not unitized (and used for something like dot product). in our actual code I think it probably gets unitized enough times that it doesn't matter.
[11:00:49] <seb_kuzminsky> heh
[11:01:36] <seb_kuzminsky> if we had that dot product bug, we'd probably still not know about it because we dont have test coverage of motion's output (except for skunkworks)
[11:02:00] <cradek> that is true
[11:02:32] <seb_kuzminsky> somewhere i have some commits that change SAI to exclude fewer things frmo its output
[11:02:33] <cradek> I did a test of g0 x0 y0 z0; g3 r1 x1 y1 z1 in the different planes and verified that they give different helixes
[11:03:13] <cradek> we would probably not have noticed the wrong helixes
[11:03:52] <skunkworks> so is there a bug?
[11:03:58] * skunkworks head is spinning
[11:04:01] <cradek> only a cosmetic one
[11:04:06] <skunkworks> ah
[11:04:20] <cradek> we think
[11:04:23] <skunkworks> heh
[11:06:09] <cradek> it would be fun to make sai print those extra things, then update the tests in 2.6 accordingly, and then see what it catches (other than these two things)
[11:07:55] <cradek> if the tests pass currently in 2.6, and I add sai output and change nothing else, is it the case that I'm justified in automatically calling the new test output correct?
[11:08:28] <cradek> seb_kuzminsky: wait did you say you've already done the sai work?
[11:10:00] <Roguish> seb_kuzminsky: a normal, in math, is a vector, of unit length. a single unit of whatever one is working in. microns, or lightyears.
[11:10:18] <cradek> Roguish: we all totally know that :-)
[11:10:26] <Roguish> sorry.
[11:10:43] <Roguish> back to work.
[11:10:45] <cradek> heh, it's ok
[11:11:01] <Roguish> i mean i'll go back to work......
[11:11:07] <seb_kuzminsky> heh me too
[11:11:37] <seb_kuzminsky> cradek: i updated sai as part of chasing #439, but then i chickened out and rebased those commits out
[11:11:44] <cradek> aww
[11:11:48] * seb_kuzminsky looks under the couch
[11:12:19] <seb_kuzminsky> iirc there were more than a few things that had to change to support it
[11:12:25] <seb_kuzminsky> sai doesn't track UVW at all
[11:13:17] <cradek> is something hard about it, or is it just more new code than you'd prefer?
[11:13:31] <seb_kuzminsky> nothing hard, just a lot of changes
[11:13:40] <seb_kuzminsky> and matching updates to each test that's affected
[11:13:44] <cradek> yeah
[11:13:51] <cradek> that's why I was wondering aloud about that process
[11:13:55] <seb_kuzminsky> yeah
[11:14:07] <seb_kuzminsky> it's probably an ok change for a stable branch, since it's not user-facing at all
[11:14:08] <cradek> I think you could just accept the new results
[11:14:54] <cradek> yeah, I agree, probably ok
[11:15:13] <cradek> (although I'd also accept a no as justified)
[11:15:59] <cradek> but I'd do the same process in that case - doing it in a branch off of 2.6 and then merging that into 2.7
[11:16:52] <seb_kuzminsky> so you could see the results in 2.6 without actually having the change in 2.6?
[11:17:10] <cradek> yeah
[11:17:55] <seb_kuzminsky> if it reveals any actual bugs in 2.6, they should be fixed, and you'd probably want the sai changes in 2.6 too, to verify the fix
[11:18:17] <seb_kuzminsky> erhm, while we're talking about changing the format of sai's output, i propose this:
[11:18:27] <seb_kuzminsky> - N..... ARC_FEED(1.2000, 2.0000, 1.0000, 2.0000, 1, 0.0000, 0.0000, 0.0000, 0.0000)
[11:18:30] <seb_kuzminsky> + N..... ARC_FEED(1.2000, 2.0000, 1.0000, 2.0000, rot=1, 0.0000, A=0.0000, B=0.0000, C=0.0000, U=0.0000, V=0.0000, W=0.0000)
[11:18:46] <seb_kuzminsky> (ie, adding argument names, so the values are easier to scan with your eyeball)
[11:18:58] <cradek> what are the first four?
[11:19:07] <cradek> I mean did you leave them unmarked on purpose?
[11:19:07] <seb_kuzminsky> start point and centerpoint of the arc
[11:19:17] <seb_kuzminsky> the axes are not know in Canon
[11:19:24] <cradek> endpoint I bet
[11:19:47] <cradek> oh right, they come in various orders don't they
[11:19:49] <cradek> bleh
[11:19:50] <seb_kuzminsky> err, yeah
[11:19:58] * cradek shivers
[11:20:17] <seb_kuzminsky> and argument 6 is the endpoint of the 'axis' of the arc
[11:20:50] <seb_kuzminsky> sai could keep track of the g17/g18/g19 mode (maybe it does already) and annotate the arc correctly
[11:21:02] <cradek> so assuming g17 it's endx endy centerx centery rot endz enda endb ...
[11:21:09] <seb_kuzminsky> yes, it tracks the active plane
[11:21:15] * seb_kuzminsky switches back to vim
[11:21:47] <cradek> we're deciding sai's output is for humans to read/understand/manipulate?
[11:22:20] <cradek> I think in the case of tests that's correct. does sai have other uses we'd be disturbing?
[11:22:41] <cradek> (I sure don't use it for anything else)
[11:22:45] <seb_kuzminsky> not in-tree, as far as i know
[11:22:55] <seb_kuzminsky> sigh
[11:22:59] <cradek> then I like your change
[11:23:30] <seb_kuzminsky> i think we should take the concervative approach and treat sai's output as one of our public interfaces, and not change it in 2.6 or 2.7 :-(
[11:24:09] <cradek> hmm
[11:24:50] <cradek> I won't argue with you
[11:25:32] <cradek> I think it'd still be very nice to see the new results of 2.6 against 2.7, even if it doesn't go in those branches
[11:26:12] <cradek> or week-ago 2.7 to see if it catches that regression too
[11:29:01] <Roguish> hey, you programmer guys. is there an 'development environment' thing for python in Linux (debian)
[11:30:19] <cradek> in linux, usually languages don't each come with their own editor/environment, so you can find various solutions according to your goals. I think the clearest answer to your question is no
[11:30:58] <jepler> https://wiki.debian.org/ProgrammingApplication
[11:31:03] <cradek> there are environments of the type I think you're asking about; I think eclipse is a popular one, emacs has some integration between languages and debuggers etc, probably there are many more
[11:31:14] <Roguish> ok, thanks. which 'editor' do you use?
[11:31:41] <skunkworks> heh - don't start!
[11:31:44] <cradek> I use more than one choice, depending on my task and feelings
[11:31:49] <cradek> but that shouldn't matter to you
[11:32:01] <cradek> yeah skunkworks has seen this kind of discussion before :-)
[11:32:03] <seb_kuzminsky> i feel strongly that cradek's choice is wrong
[11:32:09] <cradek> oh you
[11:32:29] <archivist> use your favourite that does not mangle line endings or character sets
[11:32:31] <cradek> that wiki page looks useful
[11:32:39] * skunkworks incerts relevent xkcd comic
[11:32:47] <Roguish> alright, didn't mean to start anything. i signed up for a python class through Udemy.
[11:32:54] <cradek> cool
[11:33:28] <archivist> editor discussions always start a fire :)
[11:33:33] <Roguish> not to be a programmer, but to at least understand a bit, and not be an idiot.
[11:33:38] <cradek> you didn't start anything :-)
[11:33:50] <cradek> archivist: only among people who haven't been around the block a few times
[11:33:53] <Roguish> in windows, I favor Notepad++
[11:34:51] <Roguish> got a friend that still uses edlin
[11:34:54] <archivist> I used syn when I last used windows seriously
[11:35:24] <cradek> amazingly, I guess I haven't ever programmed on windows
[11:35:37] <cradek> not more than trivially anyway
[11:36:00] <jepler> if you're going to contribute to LinuxCNC the main requirement for a text editor are: * can edit a file without making whitespace changes that are not specifically requested * can make indentation "like surrounding code", which unfortunately is not today consistent in all files
[11:36:31] <jepler> many fancy programmers' editors fail on one or both of these requirements
[11:36:50] <cradek> ... shockingly
[11:38:33] <Roguish> how's gedit do with those reqs?
[11:38:56] <cradek> I'm not sure
[11:39:34] <cradek> I suspect it doesn't do auto-indentation at all
[12:20:38] <mozmck> eclipse actually does really well.
[12:20:54] <mozmck> I think kate does well also.
[12:21:32] <cradek> I think both of those fail at requirement #1 until you carefully configure them - so be careful if you're starting fresh
[12:22:09] <cradek> (my information might be old)
[12:22:40] <ssi> vim handles it pretty well :P
[12:24:05] <cradek> heh in [day job]'s wiki there are eclipse instructions 24 steps long to configure things like don't mangle the whitespace
[12:24:42] <ssi> in the golang world the best practice is to use gofmt as a precommit hook so everything goes into the repo in exactly the right format and style
[12:25:55] <jepler> to me that's horrifying, but maybe the formatter for go is 1000x better than the formatters I have used for C++
[12:26:06] <cradek> I'm with this one
[12:26:06] <ssi> it's quite good
[12:26:14] <ssi> go has a pretty opinionated style
[12:26:22] <ssi> for instance, brace on next line is a syntax error
[12:26:28] <jepler> it would also help if it had *always* been the practice in a project
[12:26:36] <ssi> which is either awesome or horrible depending on your bias :)
[12:27:38] <jepler> because otherwise to adopt automatic formatting you have to have a flag day where you turn every pre-formatting branch into a mess of time-consuming merge conflicts
[12:28:53] <ssi> but yea I know what you mean, there's nothing more infuriating than doing a pull and having every file in the repo suddenly grow a bunch of ^M's
[12:29:01] <cradek> yargh kill kill
[12:29:26] <cradek> no jury of my peers would convict me
[12:29:32] <ssi> hahaha not if they were true peers :)
[12:29:47] <mozmck> In eclipse you go to Window->Preferences, and in the dialog go to C/C++->Editor->Save Actions and un-check "Remove trailing whitespace" if it is checked.
[12:30:07] <mozmck> I think that's all I had to do from the default setup.
[12:30:11] <jepler> I think you may not know what "peer" means in a legal context. :-P but it's funny to say it
[12:35:25] <mozmck> reading the Go docs: Why do people not like type systems? I find not having them to be a real pain.
[12:35:42] <ssi> mozmck: ? go has a type system
[12:36:02] <mozmck> https://golang.org/doc/faq#What_is_the_purpose_of_the_project
[12:36:12] <mozmck> under What is the purpose of the project?
[12:36:20] <jepler> > There is a growing rebellion against cumbersome type systems like those of Java and C++, pushing people towards dynamically typed languages such as Python and JavaScript.
[12:36:30] <jepler> C++ is the definition of a cumbersome type system
[12:36:34] <ssi> yea but that doesn't mean go doesn't have a type system
[12:36:37] <mozmck> I've used basic, and now Python, and I *really* like type systems.
[12:36:48] <ssi> I think what they're getting at is that it's a static/strong type system that's not as cumbersome as c++ or java
[12:36:50] <jepler> but you can't say Python doesn't have a type system
[12:36:50] <mozmck> as well as lua and others.
[12:37:02] <jepler> it doesn't require you to ever declare a type, but that's different than not having a type system
[12:37:08] <ssi> python has a type system, but it's dynamic
[12:37:11] <seb_kuzminsky> stronger typing would help us avoid bugs like the "convert program coordinates to canon coordinates multiple times by accident" one
[12:37:30] <ssi> go's type system is pure strong/static
[12:37:38] <jepler> even languages where 1 + "1" + [1] is well-formed and has a defined result have type systems
[12:37:38] <ssi> but it doesn't have inheritance
[12:37:39] <mozmck> re python, true, because it gripes if you do something wrong.
[12:37:41] <jepler> .. just bad ones
[12:38:01] <mozmck> But that's where I like the static type system - you know what type it's supposed to be to start with.
[12:38:09] <ssi> jepler: I'm fairly sure when mozmck says "type systems", he means "strong/static type systems"
[12:38:18] <mozmck> I think so - yes
[12:38:46] <ssi> php has a type system
[12:38:54] <ssi> just nobody has figured out deterministically how it behaves in all cases
[12:39:34] <mozmck> modern C++ has some really nice features, including "auto" which can I guess act as a weak type?
[12:44:55] <seb_kuzminsky> cradek: i just realized, sai can't find bug #439 because it was in Canon, not Interp
[12:45:10] <seb_kuzminsky> interp passed reasonable things to ARC_FEED(), and ARC_FEED() passed wrong things to Motion
[12:45:43] * seb_kuzminsky throws out his branch again
[13:07:44] <skunkworks> interesting..
http://linuxcnc.org/index.php/english/forum/27-driver-boards/29742-pidicnc-control-system
[13:07:58] <skunkworks> Pi 2 with spi
[13:08:33] <skunkworks> ugh - does video suck on the rpi2 also? (they show axis running and it is pretty choppy)
[13:09:56] <seb_kuzminsky> skunkworks: neat!
[13:19:22] <PCW> Is it using the RPI2 video? its machinekit so it might be remote on a PC/whatever
[13:32:03] <jepler> skunkworks: yes, opengl as AXIS uses it is not accelerated on rpi
[13:33:33] <cradek> seb_kuzminsky: yuck, you're right
[13:37:37] <jepler> anyway, Python has accepted a proposal for those who want to write specifications about types in their Python code.
https://mail.python.org/pipermail/python-dev/2015-May/140104.html
[13:37:41] <jepler> https://www.python.org/dev/peps/pep-0484/
[13:37:53] <jepler> > For example, here is a simple function whose argument and return type are declared in the annotations:
[13:37:56] <jepler> def greeting(name: str) -> str:
[13:37:59] <jepler> return 'Hello ' + name
[13:39:05] <jepler> and actually on closer reading, that is already a valid program in Python 3.2.
[15:12:30] <seb_kuzminsky> cradek: so i think we need to write a mock motion program that logs incoming emcmot commands, and use that for testing the task/inter/canon jumble
[15:18:39] <cradek> didn't you do that or at least start it once already?
[15:18:49] <cradek> or was that the opposite thing
[15:38:20] <seb_kuzminsky> i started the opposite thing - a program encapsulating motion's behavior, that would run as a regular process, take emcmot input commands (and hal pin pokings), and write the joint coordinate waypoints to a file, to test motion's behavior
[15:38:36] <seb_kuzminsky> ... i still have it, unfinished, somewhere
[16:12:51] <jepler> 7i92 has 4.7k pull-ups to 5V. EasyDriver has 10k pull down on /ENABLE (active low). So with both pulls active, it gets about 3.4v.7i92 outputs have a 4.7k pull-up. The stepper driver has a 10k pull-down on active-low ENABLE. That gives ~3.4V which is in the undefined voltage range. (<.3*VCC for low, >.7*VCC for high, VCC is nominal 5V)
[16:13:41] <jepler> so I guess I actually need to strengthen the pull up to get motor amplifiers off when linuxcnc is not running
[16:15:29] <PCW> If off is low you need to strengthen the pulldown
[16:16:29] <jepler> off is high
[16:17:08] <jepler> and there's a pull-down (to enable by default) because this is a board for CNC glue gun types
[16:17:29] <jepler> I guess I could remove the pull down instead
[16:18:53] <jepler> I'm less sure what to do about the laser, which is driven by a NPN darlington (ULN200x). the 1mA from a 4.7k pull-up is enough to turn the laser on real good..
[16:20:08] <PCW> you can make the outputs pulldown with some work
[16:20:48] <PCW> ( remove W1 and connect middle pin to ground )
[16:21:14] <PCW> or put a 500 ohm pulldown on the laser pin
[16:21:21] <jepler> I wondered about that but then I read that "W1 controls the 5V I/O tolerance option"
[16:22:31] <PCW> Yeah that would make it 3.3V only
[16:23:19] <jepler> I think I'll see what happens if I add a strong pull-down
[16:25:46] <jepler> I'd rather not configure it for "easier to toast, particularly if I put it back in a junk box set that way"
[18:19:12] <jepler> I think you get the idea what's going on here...
https://goo.gl/photos/GkUVSPne7huVvVUC8
[18:27:54] <skunkworks> umm...
[18:34:27] <seb_kuzminsky> ooh shiny
[18:34:54] <seb_kuzminsky> no glasses & endmill?
[20:05:28] <jepler> glasses?
[20:09:43] <skunkworks> how is it running?
[20:18:31] <jepler> skunkworks: it is smoother with linuxcnc & mesa than it was with grbl
[20:19:31] <jepler> I am still far from knowing about what feeds are appropriate
[20:20:02] <skunkworks> I bet. grbl is an exact stop planner with fuzzy blending
[20:20:50] <jepler> and I need to tune it better, I thought I set the following error under 1mm but if I do a rapid square around the 36mm working area it is a circle on the backplot -- oops
[20:21:17] <jepler> M67E0Q0G0Y36.00
[20:21:18] <jepler> M67E0Q74.90G1Y18.00
[20:21:50] <jepler> I turn the laser on/off with M3 but set the intensity with M67E0Q# because I assumed the spindle speed is not synched with motion
[20:22:30] <jepler> the PWM control can make a difference in the perceived brightness of the spot but so far I haven't seen it make a good difference in the quality of the burn
[20:22:42] <jepler> so at the minimum it's very nonlinear
[20:23:02] <jepler> on the other hand, and I admit I haven't scoped it, switching the PWM in this way seems to give smooth motion at least most of the time
[20:25:08] <jepler> but I have several knobs to turn there, PWM frequency and some sort of linearizing curve if I can figure out a good way to measure the PWM to darkness curve
[20:40:06] <jepler> http://www.jefftk.com/p/mercury-spill
[20:47:43] <jepler> PWM laser control not particularly useful, at least at default PWM frequency
https://goo.gl/photos/rwGJVJwPDfHsnwJv8
[21:14:17] <skunksleep> Wow. That burn doesn't make sense
[21:22:06] <jepler> 0% means black, like #000000 color
[21:24:41] <jepler> varying speed, varying PWM, and dithering -- dithering gives the best result.
https://goo.gl/photos/jdcuSWDfJeyMUbP78
[21:26:25] <skunksleep> Cool
[21:47:42] <jepler> and last thing for the night, something that looks like something:
https://goo.gl/photos/3F5LceUBWN3yL85a7
[21:52:20] <skunksleep> How big is that?
[21:52:39] <skunksleep> Very neat
[21:53:17] <jepler> skunkworks: 1 x 2/3" or so
[21:53:25] <jepler> physical size: 24.6x16.7mm
[22:12:20] <fenn> you may want to apply a sharpen filter
[22:15:45] <jepler> yeah I bet there is a lot more I can do in preparing the image
[22:19:37] <cradek> cool!