Back
[00:02:05] <roltek> see you guys later
[00:02:13] <SWPadnos> see you
[03:08:50] <cradek> that's sure a peculiar bug report
[03:09:06] <SWPadnos> which one?
[03:09:16] <cradek> https://sourceforge.net/tracker/?func=detail&atid=106744&aid=1687164&group_id=6744
[03:09:28] <SWPadnos> oh - that one
[03:11:36] <jmkasunich> yes
[03:11:58] <SWPadnos> I wonder if he meant "more descriptive error codes" or something along those lines
[03:12:21] <cradek> oh maybe...?
[03:12:24] <jmkasunich> I think jepler looked at the specific fprintf call he mentioned
[03:12:45] <jmkasunich> its a "fprintf(stderr, some_error_message); exit(1)" block that is already handling some other error
[03:13:12] <jmkasunich> doing error handling on calls in an error handler is the way to madness IMO
[03:13:25] <SWPadnos> if (comp_id < 0) {
[03:13:28] <SWPadnos> fprintf(stderr, "halcmd: hal_init() failed after systemv: %d\n", comp_id );
[03:13:28] <SWPadnos> exit(-1);
[03:16:07] <jmkasunich> https://sourceforge.net/projects/robodoc/
[03:19:37] <jmkasunich> hal_init() should print a message itself if there is a failure
[03:19:40] <jmkasunich> I think
[03:20:45] <jmkasunich> I have a question....
[03:21:10] <jmkasunich> I want to remove freqgen now that stepgen can do the same things (in TRUNK of course, not in 2.1.x)
[03:21:26] <jmkasunich> should I? or should I keep it around
[03:21:42] <SWPadnos> make it print a deprecated message
[03:22:02] <SWPadnos> not in halcmd either - that's an ugly hack (IMO)
[03:22:39] <jmkasunich> any message printed directly from a RT component goes into the kernel log where nobody ever sees it
[03:23:05] <SWPadnos> hmmm
[03:23:21] <jmkasunich> actually, the issue at the moment isn't so much the code, but the docs
[03:23:30] <jmkasunich> I'm trying to update the lyx
[03:23:47] <SWPadnos> * SWPadnos runs away screaming
[03:23:52] <jmkasunich> the nice pretty block diagrams that I drew for stepgen and freqgen need revised
[03:24:30] <jmkasunich> and I really want to replace the entire freqgen section with one line that says "use stepgen velocity mode"
[03:24:52] <SWPadnos> heh
[03:25:28] <cradek> is the necessary config change fairly straightforward?
[03:25:49] <jmkasunich> change freqgen.N.foo to stepgen.N+A.foo
[03:25:59] <jmkasunich> where A is the number of stepgen channels you were already using
[03:26:15] <cradek> considering that and how probably few people are using it, I'd think you should just nuke it and fix the docs
[03:26:29] <SWPadnos> does it make sense to have stepgen export freqgen.* when the type is freq?
[03:26:39] <cradek> start the wiki page for 2.1->2.2 config updates
[03:26:40] <jmkasunich> and add "ctrl_type=p,p,p,v" to your stepgen loadrt line (if you were using 3 stepgens and one freqgen)
[03:26:53] <jmkasunich> SWPadnos: no
[03:26:57] <SWPadnos> heh - ok :)
[03:27:18] <jmkasunich> that just complicates the docs and carries a difference into the future that should have never existed in the first place
[03:27:35] <cradek> it's really the same except it takes vel instead of position right?
[03:27:46] <jmkasunich> freqgen vs stepgen? yes
[03:27:57] <SWPadnos> in V mode, does it still use accel?
[03:28:01] <jmkasunich> yes
[03:28:04] <SWPadnos> hmm
[03:28:13] <SWPadnos> did freqgen?
[03:28:15] <jmkasunich> it still takes accel and vel limits, and enforces them
[03:28:16] <jmkasunich> yes
[03:28:44] <jmkasunich> see "man freqgen" bugs section for the differences
[03:28:47] <SWPadnos> I suppose you can defeat that, so it's not always harmful
[03:29:06] <jmkasunich> set the limits to zero, and they don't limit anything
[03:29:09] <SWPadnos> ok
[03:29:27] <SWPadnos> or very high, so they're effectively unlimited
[03:29:46] <jmkasunich> yeah
[03:30:29] <jmkasunich> there is a visible difference between zero and very high
[03:30:40] <jmkasunich> if you set the param to zero, it stays zero
[03:30:57] <jmkasunich> if you set it to very high, it gets reset to the maximum possible velocity
[03:31:05] <SWPadnos> I was thinking more of accel
[03:31:33] <SWPadnos> since freqgen might be used for a servo/spindle on the output of a PID
[03:31:45] <SWPadnos> so you wouldn't want any extra ramping of vel
[03:32:34] <jmkasunich> for accel there is a difference too
[03:32:39] <jmkasunich> zero means no limiting at all
[03:33:01] <jmkasunich> if you set it very high, it gets reset to "zero to maximum vel in one period"
[03:33:11] <jmkasunich> AND that level of ramping is implemented in the fast thread
[03:33:38] <jmkasunich> so although it can go from zero to max in 1mS, it will actually ramp within that one ms period
[03:33:47] <SWPadnos> ah - ok
[03:33:53] <jmkasunich> zero will step from zero to max at the beginning of the 1mS period
[03:34:05] <SWPadnos> right
[17:49:53] <jmkasunich> jepler: did you see the message from Stuart Stevenson?
[17:50:02] <jepler> jmkasunich: yes
[17:50:17] <jmkasunich> I think this isn't the first time someone's posted a message about axis not finding its history file....
[17:50:32] <jepler> that message is not fatal
[17:50:34] <jmkasunich> probably when they upgrade from a version that doesn't have history....
[17:50:35] <jepler> it's the other message "Togl" that is
[17:50:41] <jmkasunich> duh
[17:54:05] <jepler> nothing about that is different from 2.1 to TRUNK
[17:54:15] <jepler> he's invoking emc in some different way than he does normally, but he didn't say what it was
[18:02:23] <jmkasunich> looks to me like he invoked it from the command line
[18:02:35] <jmkasunich> stustev@linuxcnc1:~/emc2-head$ scripts/emc
[18:02:35] <jmkasunich> EMC2 - pre-2.2 CVS HEAD'
[18:03:06] <SWPadnos> I was going to say that he didn't tell us how he compiled/ran, but then I saw that it looks like RIP
[18:03:20] <SWPadnos> not that we know he did all the steps appropriately
[18:03:30] <jmkasunich> the run looks like RIP, the compile? who knows...
[18:03:38] <SWPadnos> right
[18:04:09] <SWPadnos> the output from emc_print.txt looks like it's correct for RIP though
[18:04:44] <SWPadnos> no EMC2_DIR - dunno if that's normal
[18:06:12] <jepler> I meant he is running it over ssh or in vnc or something like that
[18:10:57] <jmkasunich> oh
[18:11:05] <jmkasunich> I guess we can ask
[18:18:39] <jmkasunich> hmm... thats odd
[18:18:46] <jmkasunich> I ran emc (head, in place)
[18:18:56] <jmkasunich> and it didn't update ~/emc_print.txt
[18:19:22] <jepler> it doesn't when everything is OK (iirc)
[18:19:27] <jmkasunich> oh
[18:19:41] <jepler> it writes the log to somewhere in /tmp, and uses mv (or cp) when it's exiting with an error
[18:19:42] <jmkasunich> darn... hard to compare a good run to stuarts then
[18:19:59] <jepler> you can make axis exit with an error: killall axis
[18:21:40] <jmkasunich> ok, my run looks exactly like his (except for paths of course, my home dir vs. his)
[18:21:51] <jmkasunich> so "no EMC2_DIR" must be normal
[18:23:04] <jepler> none of the code near "Togl: couldn't get visual" has changed since 2.1 -- probably not since it was checked into emc2
[18:23:27] <jepler> src/emc/usr_intf/axis/extensions/togl.c is still rev 1.1
[18:23:30] <jmkasunich> so its a system thing, maybe X config, maybe because he's running remote, etc
[18:23:42] <SWPadnos> tkemc wouldn't work if there was no X
[18:23:52] <SWPadnos> though GL wouldn't be needed there
[18:24:04] <jepler> right, that's what I suspect anyway
[18:24:29] <SWPadnos> maybe someone should ask if he can open the TkBackplot window
[18:24:55] <jepler> that's not opengl is it?
[18:25:12] <jmkasunich> I'm about to write a reply (unless somebody else wants to - I'm just gonna be paraphrasing what you guys have said so far)
[18:25:37] <cradek> the consensus is he must be trying to display remotely to a bogus X server?
[18:26:01] <jmkasunich> if that was the case, tkemc should be busted too, I think
[18:26:09] <jmkasunich> it must be something more complex than that
[18:26:14] <cradek> only bogus for GL
[18:26:35] <jepler> most "vncserver"s, for instance, don't have support for the GLX extension
[18:27:05] <jmkasunich> one of you guys should reply to him- you know what you are talking about
[18:27:21] <jmkasunich> tell him to get his ass on IRC and we'll get him fixed up ;-)
[18:28:08] <jepler> though when I run in vncserver, I get a different error, 'X Error of failed request: BadWindow (invalid Window parameter)'
[18:28:39] <cradek> what if you run vncserver in 8 bit color?
[18:30:02] <cradek> X Error of failed request: BadWindow (invalid Window parameter)
[18:30:03] <cradek> Major opcode of failed request: 3 (X_GetWindowAttributes)
[18:30:18] <cradek> this is also what I get when displaying to xfree86-3
[18:31:34] <cradek> rayh: any progress on mini? will you want to put changes in 2.1.4 release?
[18:31:50] <jepler> yuck -- togl is really not very pleasant to read
[18:32:13] <jepler> I'm pretty sure this code re-tries getting an OpenGL compatible window some hardcoded number of times, without changing the window properties requested
[18:32:24] <jepler> /* It may take a few tries to get a visual */
[18:32:24] <jepler> for (attempt=0; attempt<MAX_ATTEMPTS; attempt++) {
[18:32:40] <jepler> (but nothing inside varies based on 'attempt' or is changed as a side effect, as far as I can see)
[18:33:06] <jepler> oh wait -- there is something
[21:24:04] <jepler> boy I need to spend a few weeks away
[21:24:06] <jepler> luckily I will
[21:24:31] <alex_joni> heh.. where at?
[21:24:56] <jepler> germany
[21:25:00] <alex_joni> oh nice.. :)
[21:25:16] <alex_joni> MrSunshine <- isn't tha bo^dick?
[21:27:23] <jepler> 22:38:21 <Bo^Dick> i'm thinking of this simple circuit,
http://www.carmi.se/misterstarshine/img/currlim.gif
[21:27:26] <jepler> no, I don't think so
[21:27:30] <jepler> but maybe, who knows
[21:29:20] <alex_joni> ahh.. that was starshine, not sunshine ;)
[21:45:02] <alex_joni> hahaha : " I have talked to my IT guy. He is very afraid of the irc."
[21:45:10] <alex_joni> bad things happen here
[21:53:48] <jepler> "what should FERROR and MIN_FERROR be on a stepper machine" is an interesting question
[21:54:14] <jepler> mostly they are not useful, but how can you be sure the value you choose will never give an ferror under normal circumstances?
[21:54:32] <alex_joni> yes and no
[21:54:46] <jepler> MIN_FERROR = 1/step_size, FERROR = (distance moved in 1 servo period at max speed) ?
[21:54:46] <alex_joni> you are forgetting that stepgen has it's own will.. (accel & vel constraints)
[21:55:24] <alex_joni> I'm sure that will trip sometimes
[21:55:40] <jepler> yes -- when you set it tightly you are doing some error checking that the trajectory planner is following its constraints, but assuming we ship software without bugs of that nature...
[21:56:15] <alex_joni> well.. theoretically I think you're right
[21:56:48] <jepler> I wonder how the new stepgen figures in -- I understand it give sub-step position feedback
[21:57:18] <alex_joni> right.. forgot about that
