Back
[00:16:04] <linuxcnc-build> build #2675 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/2675 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andy pugh <andy@bodgesoc.org>
[00:18:23] <linuxcnc-build> build #2677 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/2677 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andy pugh <andy@bodgesoc.org>
[00:31:49] <linuxcnc-build> build #2687 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2687 blamelist: Sebastian Kuzminsky <seb@highlab.com>, andy pugh <andy@bodgesoc.org>
[06:20:27] <jthornton> seb_kuzminsky, good fix on the asciidoc paths
[07:37:46] <jepler> *** warning: bad links found in English docs!
[07:38:00] <jepler> jthornton: can you look into it when you get a chance?
[07:39:05] <jepler> Code: 404 File `/home/buildslave/emc2-buildbot/precise-i386/precise-i386-sim/build/docs/html/code/asciidoc.css' does not exist
[07:39:15] <jepler> hm this doesn't seem like just a mistake typing a link name
[07:40:29] <jepler> OK, it is specifically because of seb's change, so I'll let him look at it
[07:41:23] <jthornton> ok
[08:31:31] <cradek> how odd - the packaged mesaflash works fine for me, I just used it the other day.
[09:13:17] <seb_kuzminsky> jepler, jthornton: yep, that looks like my goof
[09:13:37] <seb_kuzminsky> o
[09:14:31] <seb_kuzminsky> whee, another ubc3 thread! and with snyde remarks about how lazy and selfish the linuxcnc developers are
[09:14:36] <seb_kuzminsky> just what i wanted this morning
[09:15:00] <jepler> it's hard to be civil and it's hard to hold one's tongue
[09:15:37] <CaptHindsight> yes, it looks like that Gentoocnc is another boondoggle
[09:16:03] <CaptHindsight> the work they did is still valuable
[09:17:27] <CaptHindsight> it looks like they wanted to use if for glue guns
[09:19:09] <CaptHindsight> and just about every project involved with those apps seems to be void of any civility
[09:42:39] <cradek> my understanding is we have a good clean framework for adding support for more realtime systems. if someone wants to do that, they should absolutely do it
[09:43:11] <cradek> if someone thinks merging ubc3 is the way forward with adding support for a new realtime system, they simply haven't been paying attention at all
[09:43:46] <cradek> on the other hand, if someone just wants to be snarky I have no desire to get drawn in and be called names
[09:44:00] <cradek> so I guess I just shrug
[09:49:58] <seb_kuzminsky> in the email thread, ebo did not say he wanted ubc because of the additional realtime kernel it adds suport for, he said he wanted it for one of the other features it adds
[09:50:38] <jepler> luckily ebo is free to use any software he chooses to use
[09:50:41] <cradek> oh ok, I'm mistakenly combining it with a different thread in my head
[09:52:08] <cradek> are you sure? I think it's about "building for more than just a single kernel" (his words)
[09:52:29] <cradek> it's maybe not quite clear which of the things in ubc3 he wants
[09:54:07] <CaptHindsight> xenomai is just going to be preempt_rt
[09:55:07] <seb_kuzminsky> cradek: you're right
[09:55:34] <seb_kuzminsky> i interpreted it as wanting the part of the fork that lets one invocation of "make" produce executables for multiple realtime systems
[09:55:39] <seb_kuzminsky> but who knows
[09:55:40] <CaptHindsight> preempt_rt and our own branch of RTAI (well everyone is free to share it) build fine
[09:56:10] <cradek> yep, and yay
[09:56:41] <CaptHindsight> someone could add xenomai but what would be the benefit?
[09:57:05] <seb_kuzminsky> someone would also have to produce a xenomai kernel for us to use
[09:57:09] <cradek> I don't know, and I also don't know if that's what EBo wants
[09:57:29] <CaptHindsight> maybe there are differences in the performance on ARM
[09:58:40] <CaptHindsight> not sure how well preempt_rt performs on the BBB, which is probably the main interest people have in ubc3
[09:59:20] <pcw_home> At least for our Ethernet stuff, uspace is much nicer than xenomai/RT-net. its simple to set up and just works
[10:06:42] <pcw_home> cradek: does your mesaflash show the --list option?
[10:06:53] <cradek> hm lemme see if it's on
[10:07:21] <cradek> chris@emc:~$ mesaflash --list
[10:07:21] <cradek> Segmentation fault
[10:07:24] <cradek> haha yep
[10:07:47] <cradek> ii mesaflash 3.0.0 i386 Mesa Electronics utility tool
[10:07:52] <cradek> so it is crashy for me too
[10:08:01] <cradek> I didn't understand that he was saying it was just --list that crashes
[10:09:18] <cradek> there's a new post on
http://bodgesoc.blogspot.com/
[10:10:58] <cradek> > I too, am unable to run from line with my lathe and have CSS work correctly.
[10:11:27] <cradek> this might be a bug, not a design limitation...
[10:17:05] <pcw_home> I think the mesaflash version that crashes with --list also crashes if a connector just has GPIO
[10:25:22] <seb_kuzminsky> pcw_home: i'm ready to build new mesaflash debs when micges tells me he's ready
[10:25:36] <cradek> I was just going to wonder about that
[10:25:50] <pcw_home> OK great
[10:25:51] <cradek> you tried to build the 3.1 branch but it went badly somehow?
[10:26:50] <pcw_home> I must have a better vintage 3.0, everything works...
[10:27:06] <cradek> it's unfortunate when version numbers go wrong like that
[10:27:33] <cradek> I'm really glad we're packaging and distributing mesaflash now
[10:29:06] <pcw_home> I really appreciate it, since its really a necessity with the flash booted FPGA cards
[10:30:31] <pcw_home> (and the readhmid option allows you to verify whats in the config if there's any question)
[10:30:54] <cradek> yep I did that a lot recently
[10:31:12] <cradek> I wished at the time it could tell me the name of the file I used to flash it
[10:31:24] <cradek> I knew it was one of these dozen .pin files, but it was very hard to figure out which one
[10:32:45] <pcw_home> If I had been a bit smarter I would have put the config name in the IDROM :-(
[10:33:04] <cradek> if only we were all smarter
[10:34:10] <pcw_home> IDROMV4 has this along with daughtercard hints, should it ever get finished
[10:34:55] <pcw_home> and a saner register/instance stride scheme
[10:37:04] <seb_kuzminsky> cradek: the 3.1 branch built but was lacking a commit to debian/changelog to change the version number, so it was still called 3.0.0
[10:37:53] <seb_kuzminsky> we have enough different versions called 3.0.0 floating around, we dont need another ;-)
[10:38:37] <pcw_home> bad, better, betterer?
[10:41:37] <seb_kuzminsky> asch, i'm just going to ignore cmorley and andypugh in the current kvetching threads, no good will come of trying to engage
[10:49:44] <cradek> if you want to spend energy on it, try figuring out the g96 thing which is probably an actual bug
[11:11:19] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 65425ef 06linuxcnc 10docs/src/Submakefile fixup docs build * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=65425ef
[11:23:43] <skunkworks> 2.7 has the new trajectory and uspace - correct?
[11:24:29] <skunkworks> I think that is right
[11:25:04] <cradek> yes
[11:27:06] <seb_kuzminsky> yes
[11:27:40] <seb_kuzminsky> garrr no, why do i keep replying to that thread
[11:31:21] <jepler> I don't think it's dgarr's fault
[11:32:15] <seb_kuzminsky> heh
[11:32:30] * seb_kuzminsky <-- this guy's fault
[11:32:50] <seb_kuzminsky> i think today would be a good day for me to ignore the mailing list
[11:33:23] <seb_kuzminsky> i have a bad combination of butthurt and indignant righteousness
[11:46:30] <skunkworks> I think there needs to be a reference sheet as to why ubc wasn't merged into linuxcnc. (I don't know all the reasons..) People seem to be under the impression that ubc was this great idea that you guys decided not to merge. Maybe a wiki page. Just a thought. So when it comes up you can just point to this doc..
[11:47:51] <cradek> I think that would just add inflammation.
[11:51:27] <skunkworks> it comes off as you guys being jerks instead of being in the best interest of linuxcnc. but maybe there is no way to work this out.
[11:52:47] <skunkworks> crap - I have to run. bbl
[11:58:59] <jepler> The problem is that if you try to explain the technical reasons behind not merging UBC3, many users do not have the technical background to evaluate the claims. If you try to explain it in terms of personalities and agendas, it becomes both ad hominem and entirely subjective too.
[11:59:33] <pcw_home> I'm not sure what of value its brought in with UBC3 at this point
[11:59:51] <cradek> the technical reasons are all in the list history for anyone to read
[12:00:43] <jepler> cradek: that is true too
[12:01:13] <jthornton> I just noticed that Axis will allow you to press the run button with no program loaded and throws a blank error ie just the red x
[12:01:31] <cradek> how do you get there to be no program loaded?
[12:01:46] <jepler> pcw_home: ubc3 has hardware drivers for bbb which we don't have, and support for xenomai which we don't have
[12:02:30] <jepler> those are two concrete things that I know of and which I wouldn't reject if somebody came along with a nice patchset to add them
[12:02:41] <pcw_home> OK I knew about the Xenomai but didnt know it already had the BBB drivers built in
[12:03:00] <jepler> yes, they have drivers for PRU with stepgen configuration and PRU with servo&encoder configuration
[12:03:32] <jepler> iirc
[12:03:32] <jthornton> cradek, it's an ini selection OPEN_FILE = /full/path/to/file.ngc - The file to show in the preview plot when AXIS starts. Use a blank string "" and no file will be loaded at start up.
[12:03:47] <cradek> heh
[12:04:00] <cradek> that was certainly not an expected configuration
[12:04:20] <jthornton> makes sense to me to not open Axis with the same file as I almost never use the same file
[12:04:58] <cradek> I think since adding the splash screen we never worried about the state where there would be no file loaded
[12:05:26] <cradek> do you also get a startup error when trying to load the file?
[12:05:32] <jthornton> sounds plausible to me
[12:05:54] <jthornton> when I load the first file?
[12:06:29] <cradek> no I mean when it starts up and tries to load ""
[12:06:43] <jthornton> btw, the refresh button behaves properly and is grayed out until you load a file
[12:06:56] <jthornton> no, it just starts Axis and I can home
[12:07:01] <jthornton> then load a file
[12:07:52] <jthornton> no biggie, I just noticed it and thought I'm mention it
[12:08:03] <jthornton> be back later
[12:16:57] <jepler> actually it's part of our campaign to remove all the error message texts
[12:17:06] <jepler> the experienced user will know what the problem is based on the red "X" alone
[12:17:43] <pcw_home> Its a zen error
[12:49:04] <pcw_home> hmm default second ioaddresses of 7i43 and 7I90 are incorrect
[14:57:59] <andypugh> Do we want offset-when paused?
[14:59:47] <andypugh> https://github.com/mhaberler/machinekit/commit/6b0aaf39b81cc6507de41b5a74a6b0414744ea38.patch applies (nearly) cleanly on 2.6.4 and appears to be a way to solve the superior-roll problem at the very least.
[15:01:02] <andypugh> I do not understand the politics inherent in taking a commit from Machinekit and applying it to LinuxCNC.
[15:05:38] <andypugh> But, by taking that patch, setting the new pins motion.pause-offset-x, offset-z, pause-jog-feed, pause-jog-enable to 1 the lathe config does an auto-retract and return when paused. Which seems to be exactly what they wanted.
[15:32:46] <cradek> no politics, no problem, I have done it myself. but, I dislike the particular change, because I do not find it any better than the equivalent alternative of using offset+limitN yourself in hal
[15:33:22] <jepler> andypugh: docs/developer-certificate-of-origin paragraph b is the "rule" that says you're allowed to S-o-B a patch that adds code taken from another open source project with a compatible license.
[15:34:29] <cradek> after lui is done, I wonder if a task replacement could be the next big thing
[15:34:55] <cradek> if so I'd really like to tackle this correctly at that time (use existing jog infrastructure, allow changing tool offset)
[15:35:05] <andypugh> cradek: Havign tried it, it does seem approximately the same as using offset, though from the size of the patch there must be more to it. There seems to be some sort of Python interface.
[15:35:49] <cradek> andypugh: yes I think it is pretty much the same, but implemented in a way that required lots of changes
[15:35:56] <cradek> andypugh: (I tried it too)
[15:36:05] <andypugh> I suspect that if it ws documented it would make sense…
[15:37:02] <cradek> iirc, it introduces switchable multiple planner queues
[15:37:16] <andypugh> Which does seem like the right approach
[15:37:18] <cradek> I think it's simple conceptually but was intricate to code
[15:37:32] <cradek> yeah I think that part of the approach is probably right
[15:38:00] <cradek> you could use that scheme to replay reversed jogs, for instance
[15:38:07] <andypugh> So, the complexity is using the “motion” planner for the offset, rather than limit3?
[15:38:32] <cradek> I think so, but I haven't looked at it in detail recently
[15:39:06] <cradek> my main objection is the introducing a new limited kind of jogging as hal pins
[15:39:08] <andypugh> For Superior Roll an Turning, that patch + some HAL settings probably gives them exactly what they need.
[15:39:34] <cradek> if that's all you expect, offset+limit does it without any big motion changes
[15:40:02] <andypugh> Yes, true enough, but is harder to explain.
[15:40:38] <cradek> yeah I sympathize
[15:40:41] <andypugh> (though it does need source and a recompile, so is probably significantly harder to do)
[15:40:55] <cradek> differently hard
[15:41:05] <andypugh> Did you try the sample config?
[15:41:21] <cradek> IMO diverging from the released version in production should not be done lightly
[15:41:30] <andypugh> That gives you spinboxes for each axis that end up acting like jogging..
[15:41:32] <cradek> if you can do it in hal, you win, that's the point of hal
[15:42:45] <cradek> yes I've run the sample config with the special-jog panel
[15:46:45] <PCW> If this was implemented in motion why does it use different jog inputs?
[15:46:46] <andypugh> There is probably a way to link the “offset” components to the jog-wheels even. (in the HAL version)
[15:46:52] <cradek> andypugh: I bet a offset+limit could be really easy. I can imagine having a switch on the machine panel for "lift up an inch"
[15:47:01] <andypugh> Given that the wheels will be ignored in auto mode.
[15:47:02] <cradek> PCW: because it was much easier to write
[15:47:15] <PCW> :-)
[15:47:46] <cradek> PCW: using the existing jog infrastructure would have involved massive changes in task, (more) motion, and all the guis
[15:49:49] <andypugh> A custom HAL component that linked to jogwheels, axis selection, pause-mode and did the offset and limit might be a more palatable alternative.
[15:51:08] <cradek> I don't see the python interface you mentioned?
[15:53:10] <andypugh> Is one advantage of the MAH way that it still works with nontrivial kinematics? It’s an axis jog, not a joint jog?
[15:53:16] <cradek> linking offset to a jogwheel through limitN seems really easy.
[15:53:39] <cradek> oh yes, that's very true, I'm pretty sure it must move in world mode
[15:53:46] <andypugh> python-ish stuffs:
https://github.com/mhaberler/machinekit/commit/948ca392024da0ed6bcc0fad0374a253d47b6d61
[15:54:42] <andypugh> (actually reading it, it doasn’t do anything much)
[15:55:15] <cradek> yeah I don't understand what that is - is it just the panel?
[15:55:33] <andypugh> For the lathe, then, it doesn’t matter, but that does sound like a big point in the mah-way’s favour for the wacky printers and suchlike.
[15:56:02] <cradek> sure thing, it should eventually be done in world mode
[15:56:38] <andypugh> It looks like generic persistent state stuff for the panel, mainly (which you would want)
[15:57:43] <andypugh> I think the Python might also be trying to create a track-log for backtracking
[15:57:44] <cradek> it could be smarter about checking to see if the pseudojog move is within axis limits
[15:58:20] * cradek dreams of a clean new task that we could actually change
[15:59:04] <cradek> but maybe I'm a fool for thinking we'd do it right the second time
[15:59:10] <andypugh> It’s fairly clear that jog-while-paused was absolutely not considered when the fixed and rigid machine states were defined.
[15:59:45] <cradek> yeah
[16:00:25] <andypugh> Darn-it, I am going to turn my heating on. I hope it still works.
[16:00:38] <cradek> and changing offsets while paused
[16:00:58] <cradek> to me that's an important part of a full implementation
[16:01:08] <cradek> it's really exactly the same problem
[16:01:50] <cradek> to resume, you just end up generating a single extra move of the controlled point to where you stopped your arc or whatever, then you continue
[16:01:56] <andypugh> I was looking at that as part of the tool table stuff, but that project got marooned between LinuxCNC and Machinekit :-(
[16:02:33] <cradek> I think the tool table is sure handled at the wrong layer currently
[16:02:49] <cradek> probably as is cutter comp, sadly
[16:02:55] <seb_kuzminsky> cradek: one thing that excites me about lui is that it opens the door to fixing task later
[16:02:58] <cradek> that's a bigger one
[16:03:06] <cradek> seb_kuzminsky: me too. I can clearly see that too.
[16:03:52] <cradek> andypugh: I'm sad the tool table stuff is marooned
[16:03:52] <andypugh> I wanted tool handling to be a loadable module, but that meant having HAL modules be able to field NML messages, which they can’t, but the proposed replacement could.
[16:04:22] <cradek> ooh sounds like you should join brains with the lui team
[16:04:53] <andypugh> I have no idea what you are talking about
[16:05:12] <cradek> sorry
[16:05:57] <cradek> they're making and using a new api between the guis and task. currently it wraps nml, but once there's a clean api they will be able to replace nml with something smarter
[16:06:22] <andypugh> Isn’t this a pre-solved problem?
[16:06:26] <cradek> then task can lose its remaining nml usage (interp list)
[16:08:16] <andypugh> I find it very frustrating that two teams are doing the same thing to pretty much the same software in different ways.
[16:08:53] <cradek> > If we could get this without the extra buttons just using axis controls it would be very nice.
[16:09:24] <andypugh> I wqs meaning that LUI sounds identical to Machinetalk
[16:12:31] <cradek> I have not followed what machinetalk is/does, and I agree with you that it sounds silly on the surface.
[16:12:50] <cradek> (but I'm also not doing the work on either project)
[16:15:14] <jepler> andypugh: the machinekit devs identified this as the first critical characteristic of any contribution they'll accept:
[16:15:17] <jepler> >
[16:15:20] <jepler> http://www.machinekit.io/docs/contributing/
[16:15:22] <jepler> A patch SHOULD be a minimal and accurate answer to exactly one identified and agreed problem.
[16:15:25] <jepler> <
[16:15:45] <jepler> andypugh: this is the core objection we raised every time they wanted to merge "unified-build-candidate"
[16:16:06] <jepler> andypugh: we worked for most of two years to find a way that we could merge good stuff that lived in their various branches
[16:16:10] <jepler> and we failed
[16:16:37] <jepler> trying again with machinetalk is just not a rational choice
[16:17:28] <andypugh> So now we have 2 diverging projects with 3 developers each, rather than one with 6 devs.
[16:17:47] <jepler> for various values of 3 and 6, yes
[16:17:50] <cradek> than one with 6 devs that could make no progress and no release, YES, and that is good
[16:19:15] <cradek> you saw us not release 2.6 for ages while trying to sort this out. another year of that and linuxcnc would have been dead.
[16:19:51] <andypugh> I know there is no going back now, but the current situation really sucks for those in neither camp
[16:20:27] <cradek> I'm happy both sides of the fork are making progress
[16:20:35] <cradek> I really don't think that sucks at all
[16:22:23] <cradek> I am happy there was a fork. We were all in an impossible position and now we're not.
[16:22:27] <andypugh> However, not knowing which fork to follow, and not wanting to do everything twice, I am doing nothing on the tool table.
[16:22:46] <cradek> that sucks.
[16:23:46] <cradek> the recent big shared feature (rob's tp) was easy to port from one to the other, because those parts were not much diverged
[16:23:48] <skunkworks> Feels a bit like a divorce and we have to choose which parent to live with... :)
[16:24:02] <cradek> I don't have a feel for how much your changes would be like that
[16:24:12] <andypugh> Yes, exactly like that. Or we can choose to leave home.
[16:24:38] <cradek> divorces often resolve impossible situations, with some sacrifices, too
[16:24:57] <Connor> So, we're talking mk vs lcnc ?
[16:25:02] <cradek> andypugh: I don't know what to say to help you
[16:25:05] <cradek> say or do
[16:25:42] <Connor> I thought mk was more for embedded computers..
[16:26:10] <andypugh> I don’t _need_ to be a hobby software writer, so there’s lots of other things I can do, like actually using my machine tools.
[16:26:28] <andypugh> Connor: I don’t think they know what they are at the moment.
[16:26:35] <jepler> Connor: (linuxcnc 2.7 will support ARM systems)
[16:27:00] <cradek> andypugh: yeah, me too, I understand the pull
[16:27:28] <jepler> andypugh: yeah I was affected by that in a major way while the future of linuxcnc was unclear .. did a lot less contributing during that time
[16:28:07] <andypugh> The Machinekit blog clearly says “Beaglebone CNC” but then they insist that the plan is to support any platform with a usable kernel.
[16:28:23] <cradek> (if we were still in deadlock, I would've quit by now)
[16:29:36] <andypugh> But it is hard to say what Machinekit is really as they appear allergic to documentation.
[16:29:50] <cradek> it'd be easy to concentrate on the one embedded board that's having a flash of popularity right now
[16:29:50] <andypugh> (i still haven’t found any docs for the PRU stepgen)
[16:30:21] <jepler> andypugh: at a personal level, I hope to continue to see you 'around' on IRC and the mailing lists, because you're a heck of a guy.
[16:30:38] <cradek> yeah exactly
[16:30:56] <cradek> and I was sad to see you say your bike blog was done
[16:31:18] <cradek> hope you enjoy riding it a lot
[16:31:28] <jepler> I just showed your bike blog to my father in law last night .. he was pretty impressed (though he's mostly a woodworker he also worked in auto parts stores and repair shops most of his life)
[16:31:40] <andypugh> I will probably still do HAL components, and hm2 drivers, but I don’t see me taking on anything as big as the tool table now.
[16:32:34] <andypugh> I will blog the next project I expect, but the bike is basically finished, so there isn’t anyhthing left to document.
[16:32:54] <cradek> > Is anyone in the world who uses linuxcnc and the spindle is connected through inverter to computer via USB port? Please provide me hal File.
[16:33:12] <cradek> (sigh)
[16:33:36] <cradek> it was cool to see all your remaining parts for sale
[16:33:57] <skunkworks> The big push to separate the 'realtime' from the ui is something that doesn't appeal to me at least right now.. I don't ever planning on having 2 devices to run 1 machine..
[16:33:58] <cradek> maybe your work will keep several of those machines surviving
[16:34:04] <andypugh> I don’t expect to stop doing the forum support
[16:34:51] <andypugh> skunkworks: Yeah, that seems like a wierd solution to the “Beagbone too slow” issue. Why not just use somethign that isn’t too slow?
[16:35:45] <jepler> andypugh: I think the sekrit pl@N is for that second computer to be the Windows or Mac computer the customer already expects to administer
[16:36:00] <jepler> well I don't think it's really all that secret for that matter
[16:36:11] <jepler> I'm not interested in that, because in my case it'd be a Linux computer and another Linux computer
[16:36:14] <cradek> andypugh: also "oh we'll just not use opengl because it's slow". sometimes it feels like using the particular piece of hardware that you already bought because it's cool is the primary consideration.
[16:36:24] <andypugh> Which makes the BBB something a bit like a Smoothstepper. Which isn’t a terrible plan.
[16:36:42] <jepler> but imagine the endgame in which linuxcnc is the "smoove steppa'" of mac four
[16:36:53] <jepler> yeah exactly
[16:37:08] <jepler> a $100 box which works right to spin the motors, and goes together with the computer you have
[16:37:11] <jepler> it's not daft, but it's not what I want
[16:37:18] <cradek> No match for "SMOOVESTEPPA.COM".
[16:37:18] <cradek> >>> Last update of whois database: Fri, 21 Nov 2014 22:17:00 GMT <<<
[16:37:26] <cradek> your one and only chance
[16:38:06] <andypugh> reminds me that a friend used to have “debiantart”
[16:38:09] <jepler> I already have a new domain I need to put content on
[16:38:27] <jepler> but it turns out I hate all blogging software so nothing's happening
[16:39:04] <andypugh> I had to do crazy things to not have stuff in reverse chronological order.
[16:40:24] <skunkworks> and the finding a machine that runs everything that plays well with realtime never was an issue for me..
[16:40:38] <jepler> skunkworks: you're a special case
[16:40:46] <andypugh> That 12V input J1800 looked like a winner.
[16:40:51] <andypugh> (J1900)
[16:41:54] <andypugh> Somebody should buy one and tell me if the latency is any good :-)
http://www.amazon.com/ASRock-Q1900DC-ITX-2-0GHz-Mini-ITX-Motherboard/dp/B00K70ZD64
[16:44:16] <Connor> Who are the devs for MK ?
[16:45:14] <PCW> the J1800,1900s seem fine latency wise
[16:55:36] <andypugh> cradek: Yoiu see this clock?
http://farm1.static.flickr.com/3/4657514_53908e6bb7.jpg
[16:55:57] <andypugh> Next weekend I am going up a scaff tower to see what it takes to fix it.
[16:56:19] <andypugh> It is a pulse clock that lost its master, but is now also siezed.
[16:57:41] <PCW> 1 pulse/minute?
[16:58:28] <andypugh> 2 per minute
[17:02:10] <cradek> cool, are you fixing it?
[17:02:18] <andypugh> My plan is to use an MSF time signal reciever and an Arduino to generate the pulses
[17:02:39] <andypugh> The view from inside:
https://picasaweb.google.com/108164504656404380542/UnionClock?authkey=Gv1sRgCLfkxP-0g7m8aw
[17:02:44] <cradek> MSF is the european WWVB?
[17:03:19] <andypugh> UK one
[17:03:45] <cradek> that's a very simple movement, cool
[17:03:50] <cradek> coil is ok?
[17:03:57] <andypugh> http://en.wikipedia.org/wiki/Time_from_NPL
[17:04:37] <andypugh> The rear coil seems to have overheated and oozed into the armature gap
[17:05:36] <PCW> maybe stuck on?
[17:05:39] <andypugh> I am hoping that I will be able to tell from the outside how the movement is attached to the face.
[17:06:04] <andypugh> The pulse master was replaced by a synchronous motor, cams, and microswitch.
[17:06:17] <andypugh> Perhaps the period was too long.
[17:07:13] <andypugh> I wonder what the non-inductive shunt (part K here:
http://www.britishtelephones.com/clocks/pulse.htm ) is for?
[17:08:07] <andypugh> The clock is currenly blowing a 5A fuse, so I think the coils are shot.
[17:08:47] <jepler> instead of an RC snubber or flyback diode?
[17:08:51] <jepler> (the shunt)
[17:10:38] <andypugh> The mechanism pre-dates diodes, so possibly so.
[17:11:18] <andypugh> To prevent arcing at the master, rather than anything for the slave
[17:13:22] <jepler> ah "scaff tower". scaffolding in american
[17:13:59] <andypugh> Well, a sectional tower, rather than loose tubes and clamps.
[17:41:41] <PCW> I wonder if the shunt is a early varistor
[17:59:10] <andypugh> Why do you wonder that
[17:59:11] <andypugh> ?
[18:00:17] <andypugh> And is it importantly non-inductive?
[18:07:03] <PCW> well it looks too small to be a capacitor snubber so what else could it be (spark gap?)
[18:15:43] <seb_kuzminsky> huh, heekscad/heekscam has come back to life:
https://sites.google.com/site/heekscad/
[18:16:00] <seb_kuzminsky> 10 quid (did i say that right) for a windows executable, or download the source for free
[18:28:41] <andypugh> PCW: I think it is a resistor, not inductively wound
[18:29:53] <andypugh> It is the frazzled thing near the (frazzled) terminal block (the original porcelain one was lying nearby)
[18:30:37] <andypugh> (isn’t a “shunt” always a resistor?)
[18:31:31] <PCW> yeah a resistor would limit the peak inductive kickback voltage
[19:35:47] <cradek> andypugh: if you have MSF and some cpu, maybe you could put a home switch on it and have it self-set after power outage
[19:36:57] <andypugh> I can’t help wanting an encoder on it.
[19:37:29] <cradek> did it self-set originally?
[19:37:44] <andypugh> No, they just trusted the system
[19:38:02] <andypugh> (and this clock had an “advane 30 seconds” button
[19:38:08] <cradek> aha
[19:38:25] <cradek> how terrible that must've been
[19:38:41] <andypugh> I do have a multi-turn conductive encoder spare.
[19:39:06] <andypugh> (I think it was horribly expensive new in 1950)
[19:40:15] <kwallace2> How far from original is the clock?
[19:40:58] <zeeshan|2> hi kirk
[19:41:10] <kwallace2> Howdy.
[19:41:29] <zeeshan|2> have you done vfd communication lately?
[19:43:57] <kwallace2> Not for quit a while. I would like to make a Modbus/Arduino/dumb VFD adapter, but VFDs are cheap these days and my dumb VFDs are beginning to fail.
[19:44:40] <zeeshan|2> i was curious to figure out why you like using modbus rtu for communication
[19:45:56] <zeeshan|2> most of your drivers used modbus rtu :)
[19:46:09] <kwallace2> Modbus/RTU is made for industrial control.
[19:46:29] <zeeshan|2> i have a system with 3 vfds in it currently
[19:46:35] <zeeshan|2> the 2 vfds are identical (eaton ones)
[19:46:41] <zeeshan|2> they can either use modbus rtu or ascii
[19:46:52] <zeeshan|2> but the sumitomo vfd doesn't have a rtu option
[19:46:53] <zeeshan|2> only ascii
[19:47:06] <zeeshan|2> so i think im gonna have to try to communicate using ascii
[19:49:16] <kwallace2> If you have a manual and it covers ASCII then it should not be too hard, but don't hold me to it.
[19:49:33] <zeeshan|2> i was trying to figure out what the differnce was
[19:49:43] <zeeshan|2> with ascii mode there is an end of packet
[19:49:56] <zeeshan|2> but with rtu mode a 10ms delay is percieved as end of communication
[19:50:02] <andypugh> kwallace2: As far as I know it is the original 1905 clock
[19:50:38] <kwallace2> Oops, gota go to dinner. I should be back in a little bit.
[19:57:22] <mozmck> zeeshan|2: with ascii mode, each byte is converted to 2 ascii characters
[19:57:30] <mozmck> 0-9 and A-F
[19:57:36] <zeeshan|2> yes
[19:58:06] <mozmck> twice as many bytes per packet, but no or little timing constraints
[19:59:24] <zeeshan|2> this is probably a very noob question but ill ask..
[19:59:33] <zeeshan|2> what is the point of using modbus ascii libraries
[19:59:50] <zeeshan|2> i was looking at the sample program written in the vfd manual
[20:00:20] <zeeshan|2> lemme post :)
[20:01:44] <zeeshan|2> http://pastebin.com/bDQYhY1Y
[20:03:05] <zeeshan|2> they dont make use of modbus?
[20:16:34] <mozmck> If I understand correctly, they are just sending one modbus packet that doesn't need a response.
[20:18:10] <mozmck> A library just gives you some functions to allow you to do the setup, easily change the packet contents, poll for a response, etc.
[20:20:50] <zeeshan|2> okay :)
[20:21:04] <zeeshan|2> mozmck: thats exactly what theyre doing
[20:22:44] <mozmck> :) the packet there is hard coded, generally you would have a function that could take random data, and it would convert to ascii, add the start and stop indicators and LRC and then send.
[20:26:02] <zeeshan|2> i was thinking of getting a better learning experience in communicating with a VFD
[20:26:09] <zeeshan|2> ill try from 'hardcoded packet' approach
[20:26:26] <zeeshan|2> see how things work
[20:26:32] <zeeshan|2> and then make the code more modular
[20:26:46] <zeeshan|2> i used kwallace's modbus driver for the eaton mvx9000
[20:27:12] <zeeshan|2> he was running the vfd in forward, reverse, and stopping and setting frequency
[20:27:21] <zeeshan|2> i ended up adding current monitors etc
[20:27:47] <zeeshan|2> but that was using the modbus library (didnt get too much understanding of how the process worked, just a lot of trial and error copying and pasting)
[20:29:57] <kwallace2> I just copied Micheal's VFS11 or somesuch driver and edited it to my SJ200's commands. I think someone else did the MVX.
[20:30:27] <zeeshan|2> ah :)
[20:30:45] <zeeshan|2> you know whats sweet?
[20:30:50] <kwallace2> I did a little hard coding until I started figuring things out and went on to libModbus.
[20:30:51] <zeeshan|2> once you get it working with MVX series
[20:30:56] <zeeshan|2> NFX and other eaton vfds are easy!
[20:30:58] <mozmck> the modbus spec has it all in it, not too hard to read I didn't think. There is plenty of code around to study as well.
[20:32:22] <zeeshan|2> the only thing i couldnt figure out with the mvx9000 driver was this
[20:32:53] <zeeshan|2> if i set 90.04 "transmission fault treamtnet" to 00 "display fault and continue to operate"
[20:33:07] <zeeshan|2> you would see the vfd display go crazy (saying it detects transmission faults)
[20:33:38] <zeeshan|2> i have no idea what it considers a transmission fault
[20:34:29] <kwallace2> My guess is either CRC, timing error, or a data size mismatch.
[20:34:53] <zeeshan|2> timing error is handled by another parameter (wathdog) it monitors the time between commands
[20:35:04] <zeeshan|2> adjustable from 0 to 120s
[20:35:19] <zeeshan|2> crc i think might be it!
[20:35:39] <zeeshan|2> because i didn't see anything in the driver that calculated crc the way the manual says to
[20:36:06] <zeeshan|2> LRC (Longitudinal Redundancy Check) is calculated by summing up, module 256, the values of the bytes from ADR1 to last data character then calculating the hexadecimal representation of the 2s-complement negation of the sum.
[20:36:12] <zeeshan|2> yea i definitely do not remember seeing that
[20:39:07] <kwallace2> My impression was that a bad CRC would just cause the packet to be ignored by the receiver, but the sender expects to the receiver to send a NACK with CRC back so the sender would know that the packet didn't get through. But, I've forgotten a lot of this stuff.
[20:40:32] <kwallace2> Usually I try everything I can think of until it starts working, then move on.
[20:40:39] <zeeshan|2> haha
[20:41:03] <zeeshan|2> well i was thinking if you send run/stop commands over rs485
[20:41:12] <zeeshan|2> you definitely need a watchdog to kill everything
[20:41:20] <zeeshan|2> just incase the main computer freezes
[20:41:35] <zeeshan|2> cause the other day on my lathe, thats exactly what happened
[20:41:48] <zeeshan|2> comp froze (shouldnt be surfing the web while maching)
[20:42:00] <zeeshan|2> and the steppers died cause of the chargepump
[20:42:04] <zeeshan|2> but the spindle kept spinning :)
[20:42:19] <zeeshan|2> i don't want that happenining on the mill!
[20:42:41] <zeeshan|2> i think a transmission check woulda avoided that
[20:44:03] <kwallace2> It sounds like you need to have the charge pump control your e-stop relay to cut all machine power.
[20:45:09] <zeeshan|2> on the lathe i dont have a contactor on the vfd primary
[20:45:23] <zeeshan|2> but on the mill setup i'm putting contactors on all primary sides of the servo drives, vfds
[20:45:41] <zeeshan|2> but an e-stop switch directly controls the coils of that
[20:46:31] <zeeshan|2> i will also be using one of the 7i77 field output as a watchdog
[20:47:06] <kwallace2> You just need a round to it that fits your lathe.
[20:47:17] <zeeshan|2> i have arguements with others over this but i think killing the mains on the servo drives and vfds while they're under full load
[20:47:20] <zeeshan|2> is pretty harsh
[20:47:48] <zeeshan|2> if you just kill the enables on the servo drives
[20:48:04] <zeeshan|2> also use the builtin watchdog in the vfd to stop the drive (not kill power to primary)
[20:48:09] <zeeshan|2> its a much smoother action
[20:48:49] <zeeshan|2> so you dont include the watchdog from the 7i77 field output into the e-stop chain. only the e-stop switch controlling the coils of the contactors
[20:48:59] <zeeshan|2> so in a real emergency, you can kill power in a harsh manner
[20:49:34] <zeeshan|2> this is the main reason why i'd like to use the watchdog inside the vfd in a computer freeze scenario
[20:51:09] <zeeshan|2> son of a...
[20:51:10] <zeeshan|2> "libmodbus is a free software library to send/receive data according to the Modbus protocol. This library is written in C and supports RTU (serial) and TCP (Ethernet) communications."
[20:51:14] <zeeshan|2> no ASCII! :(
[20:52:19] <kwallace2> I was running a big CNC lathe for a local shop and it had a small hydraulic leak. The reservoir got too low and threw an alarm which e-stopped the lathe with a big bag. The spindle stopped in maybe a tenth of a turn from 3kRPM, then was silent. They filled it up again and I was back to work.
[20:53:07] <zeeshan|2> was the power to the primary of the vfd killed?
[20:53:37] <zeeshan|2> it must have to be able to stop that quick :P
[20:53:53] <kwallace2> I don't know, nothing was on when it stopped.
[20:56:35] <kwallace2> My HNC lathe has a magnetic release brake that activates when the power is cut. I don't think it is big enough for an instant stop, besides I have a threaded spindle so the chuck could keep spinning.
[20:57:59] <zeeshan|2> im always overthinking stuff :P
[20:58:09] <zeeshan|2> i just try to avoid cycling capcacitors if i dont have to
[20:59:22] <mozmck> http://www.freemodbus.org/
[21:00:58] <zeeshan|2> sweet
[21:01:00] <zeeshan|2> ascii mode.
[21:01:14] <zeeshan|2> okay there is no point to hardcore when theres nice functions like this
[21:01:32] <zeeshan|2> *code
[21:02:01] <zeeshan|2> by next weekend i should have the vfds wired up. programming will commence
[21:05:31] <kwallace2> Hmmm, I keep getting page not found with FreeModbus.
[21:06:08] <zeeshan|2> if you click api documentation
[21:06:16] <zeeshan|2> you can surf through the examples
[21:06:42] <zeeshan|2> and in the examples you can click on the functions and it gives you a description of the function :D
[21:08:19] <zeeshan|2> https://www.flickr.com/photos/128539016@N05/15746739912/
[21:08:26] <zeeshan|2> bottom 3 are the vfds i need to communicate with
[21:17:30] <kwallace2> I have my doubts about FreeModbus being an active project and the Linux port talks about being only a slave.
[21:23:18] <kwallace2> Ah ha, found some source:
http://sourceforge.net/projects/freemodbus.berlios/files/
