Back
[00:39:45] <jepler> cradek: is this the bug you recently fixed? "EMC_TRAJ_CIRCULAR_MOVE not issued"
https://sourceforge.net/tracker/index.php?func=detail&aid=1901167&group_id=6744&atid=106744
[00:46:38] <jepler> BigJohnT: is it possible you missed checking an image in?
[00:46:38] <jepler> Must remake target `../docs/src/lathe/images/tool_positions.png'.
[00:46:38] <jepler> Failed to remake target file `../docs/src/lathe/images/tool_positions.png'.
[00:46:42] <jepler> make: Failed to remake makefile `Makefile'.
[01:51:28] <cradek> jepler: I could only guess, but my guess is it is fixed
[02:28:33] <cradek> fwiw, the documentation about motion.spindle-speed-out is clear and explicit about the signed behavior
[06:33:35] <CIA-1> EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/ (stepconf.py stepconf.glade):
[06:33:35] <CIA-1> EMC: Add message dialog box to warning of overwriting ladder files. Add more driver
[06:33:35] <CIA-1> EMC: default timing settings. Add check for Estop-in pin if using estop ladder
[06:33:35] <CIA-1> EMC: program. Discovered a long standing bug with trunk version driver timing will
[06:33:36] <CIA-1> EMC: not init. properly. Seems to be initializing from the wrong widget-fine in you
[06:33:38] <CIA-1> EMC: load an exsisting config
[12:30:47] <BigJohnT_> BigJohnT_ is now known as BigJohnT
[14:57:36] <BigJohnT_> well I'm down to the at-speed pin of the gs2_vfd... is there some magic to make it change states?
[14:58:36] <BigJohnT_> btw, the bug report was in error the gs2_vfd handles the negative number quite well... a senior moment I guess :/
[15:05:53] <BigJohnT_> hmm in gs2_vfd.c I only see where at_speed is created but not used hey but what do I know :)
[15:10:07] <jepler> maybe SWPadnos got bored before he finished
[15:20:24] <BigJohnT_> BigJohnT_ is now known as BigJohnT
[15:20:37] <BigJohnT> jepler: could be :)
[15:29:18] <jepler> BigJohnT: I get an error building docs on trunk .. make: Failed to remake makefile `Makefile'.
[15:29:39] <jepler> File `../docs/src/lathe/images/tool_positions.png' does not exist.
[15:29:47] <jepler> did you miss checking in a file?
[15:30:32] <jepler> bbl
[15:31:53] <BigJohnT> I'll check it out
[15:35:27] <BigJohnT> jepler: tool_positions.png is in the cvs... been there for three days
[15:36:55] <BigJohnT> hmm I guess I could take a stab at the gs2_vfd.c seems simple enough
[15:39:16] <BigJohnT> if ((frequency-command - frequency-out) < tolerance) turn on at-speed
[15:40:43] <jtr> is that correct for negative speeds as well?
[15:41:14] <BigJohnT> good question jtr
[15:41:39] <BigJohnT> both of those come from the drive and are always positive numbers...
[15:43:05] <BigJohnT> but I missed the spindle-on part of the bool ... && spindle-on
[15:43:05] <jtr> well, that sounds reasonable. I just remember cradek having his lather run the wrong way the other day.
[15:43:33] <jtr> -r
[15:44:27] <BigJohnT> might have been from motion.spindle-speed-out which goes negative with M4
[15:47:42] <jtr> it was code that limited the speed - it checked the absolute values of commanded and max speed, but always corrected to +max.
[15:48:03] <BigJohnT> ok
[15:48:57] <jtr> if you give the vfd a negative speed command does it reverse the motor, or is there a separate command to set motor direction?
[15:49:21] <BigJohnT> the gs2 uses fwd and rev to change directions
[15:49:39] <alex_jon1> BigJohnT: hi
[15:49:50] <BigJohnT> hi alex_jon1
[15:50:00] <alex_jon1> did you close that bugreport?
[15:50:18] <BigJohnT> no, I think someone else did
[15:50:21] <jtr> so it just ignores the sign completely. cool. Gotta run - bbl.
[15:50:22] <alex_jon1> ah, ok :)
[15:50:33] <BigJohnT> I went to check and it was gone
[15:50:55] <BigJohnT> c question alex_jon1 if you have a second?
[15:51:45] <alex_jon1> sure
[15:52:12] <BigJohnT> *(hal_data_block->freq_cmd) I understand the inner part is using the member selection operator but the *() what does it mean
[15:52:30] <alex_jon1> this is a HAL pin
[15:52:34] <BigJohnT> yes
[15:52:45] <alex_jon1> HAL pin gets their data allocated in the HAL struct somewhere
[15:52:53] <alex_jon1> not in the memory allocated by the driver
[15:53:00] <BigJohnT> ok
[15:53:01] <alex_jon1> the *() represents a pointer
[15:53:05] <alex_jon1> to that location
[15:53:21] <alex_jon1> actually hal_data_block->freq_cmd contains the pointer to the location
[15:53:30] <alex_jon1> and *(foo) gets the value found at that location
[15:53:32] <BigJohnT> ok I knew somehow it was a pointer in order to use the member selection operator
[15:53:35] <alex_jon1> s/gets/gets & sets/
[15:53:45] <BigJohnT> ok, cool
[15:53:50] <alex_jon1> if you have a : char *foo;
[15:53:57] <alex_jon1> then you operate using *foo = ...
[15:54:16] <BigJohnT> ok
[15:54:18] <alex_jon1> if foo is part of a struct, then you use *(struct->foo)
[15:54:54] <BigJohnT> the struct is in the componet actually
[15:55:09] <BigJohnT> I'm looking at gs2_vfd.c
[15:55:10] <alex_jon1> yes, I know.. that's how it usually is
[15:55:17] <BigJohnT> ok
[15:56:03] <alex_jon1> I don't suppose you care why it's like this :)
[15:56:24] <BigJohnT> I always care and want to learn more
[15:56:40] <alex_jon1> well.. the idea is that HAL pins belong to RT and userspace components
[15:56:59] <alex_jon1> so they need to be in the same address space (in a place called SHM = shared memory)
[15:57:08] <BigJohnT> ok
[15:57:15] <alex_jon1> so when you link signals and one pin updates another it happens immediately
[15:57:33] <alex_jon1> parameters are different beasts (close to extension :P)
[15:57:34] <jepler> BigJohnT: you're right, it's my fault
[15:57:42] <BigJohnT> ok, that makes sense
[15:57:44] <jepler> BigJohnT: new machine and I didn't put my .cvsrc file, so my script broke
[15:57:58] <alex_jon1> they are local to components
[15:58:20] <alex_jon1> they only get updated by setp commands, so they get updated rom the outside (so to say)
[15:58:33] <BigJohnT> ok
[15:58:49] <alex_jon1> I suspect jmkasunich will not be veyr happy about an explanation like this ;)
[15:59:00] <BigJohnT> LOL
[15:59:20] <alex_joni> but it should get you an idea how it works
[15:59:45] <BigJohnT> that helps a lot thanks
[15:59:49] <alex_joni> np
[16:00:01] <alex_joni> (no need for my irc backup.. finally back home ;)
[16:00:14] <alex_jon1> alex_jon1 is now known as alex_joni
[16:01:30] <BigJohnT> now lets see how many times I break it before I get it fixed or give up for the day :)
[16:03:24] <alex_joni> * alex_joni guesses 2
[16:03:40] <BigJohnT> I'll let you know...
[16:12:37] <BigJohnT> well pass #1 I made the bit come on :) now to add the bool condition
[16:36:10] <BigJohnT> pass #2 results not what was expected... experiance gained = 0;
[16:36:37] <jmkasunich> you always gain experience
[16:36:48] <jmkasunich> maybe not knowledge, but experience ;-)
[16:38:25] <BigJohnT> yep, that didn't work but why I don't know for the moment :)
[16:38:41] <BigJohnT> pass #3 results as expected
[16:55:30] <CIA-1> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/ (stepconf.glade stepconf.py): by storing a string 'driver type' things are more extensible. also, fix a bug reported by cmorley where user settings for steplen/stepspace are overridden
[16:59:20] <CIA-1> EMC: 03jmkasunich 07TRUNK * 10emc2/lib/python/pyvcp_widgets.py: major improvements to meter widget - scaled fonts, colored regions, minor ticks, nicer pointer, adjustable scales - patch by Jan Van Gilsen
[17:44:19] <CIA-1> EMC: 03jmkasunich 07TRUNK * 10emc2/docs/src/hal/ (pyvcp.lyx pyvcp_meter.png): manual changes for improved pyvcp meter widget
[17:54:46] <SWPadnos> BigJohnT, I think the gs2 has "at speed" in the status bits
[17:55:09] <SWPadnos> I don't recall if I intended to use the tolerance internally or if it's sent to the VFD
[17:55:40] <BigJohnT> * BigJohnT looks at the manua
[17:55:42] <BigJohnT> l
[17:56:08] <SWPadnos> I believe it's intended to be a fraction as well, since the default is 0.01 (I think that would be 1 percent)
[17:56:44] <BigJohnT> I don't see an at-speed on the status list
[17:56:51] <SWPadnos> ok
[17:57:08] <BigJohnT> let me watch the status while it ramps up
[17:58:00] <BigJohnT> it does not change when at speed is reached
[17:58:19] <BigJohnT> just indicates run as soon as you start it
[17:59:29] <BigJohnT> SWPadnos: you wanna see my hacked up diff on it?
[17:59:44] <SWPadnos> after coffee :)
[17:59:51] <BigJohnT> ok
[18:00:06] <BigJohnT> I mangled to get at-speed to work :)
[18:03:32] <BigJohnT> but motion.spindle-at-speed does not work as expected
[18:08:27] <SWPadnos> how do you expect it to work?
[18:10:44] <BigJohnT> I see the problem I'm getting an at-speed blip when I start
[18:10:59] <SWPadnos> yeah, 0==0 :)
[18:11:30] <BigJohnT> if (retval==0 && *(hal_data_block->spindle_on) && *(hal_data_block->freq_diff) < 1){
[18:11:48] <SWPadnos> actually, I didn't have any initialization of that output, did you add any?
[18:12:01] <BigJohnT> yes I did :)
[18:12:04] <SWPadnos> ok
[18:12:31] <BigJohnT> must be a delay between the spindle on and the freq diff changing :(
[18:12:50] <SWPadnos> one other thing - I noticed that hal_ready() was foolishly placed before all the initialization was done. If you're changing things in that file, could you move the hal_ready call below all the initialization (maybe just about he main loop)
[18:13:12] <SWPadnos> gah
[18:13:16] <SWPadnos> s/about he/above the/
[18:13:31] <SWPadnos> silly me
[18:15:43] <BigJohnT> here is what I have so far
http://pastebin.ca/1299094
[18:15:51] <jepler> motion will output a new speed one cycle and then poll at-speed the next cycle. the userspace gs2_vfd driver probably hasn't seen the new speed command by that time, and so it hasn't set its at-speed output false again
[18:15:56] <jepler> </total guessing>
[18:16:12] <jmkasunich> probably a good guess tho
[18:16:33] <jmkasunich> does the gs2 driver have an "actual speed" output to HAL?
[18:16:34] <BigJohnT> I thought I saw it give me an at-speed blip at the start
[18:16:40] <BigJohnT> yes
[18:16:50] <BigJohnT> actual Hz
[18:17:12] <jmkasunich> you should probably use a realtime comparator between the commanded speed from EMC and the actual speed from the VFD driver then
[18:17:24] <jmkasunich> any userspace driver is hopelessly slow compared to RT
[18:17:44] <jmkasunich> at-speed from the driver will never go false fast enough
[18:17:49] <SWPadnos> there will still be a race issue
[18:18:00] <SWPadnos> hmm. no, maybe not
[18:18:08] <jmkasunich> SWPadnos: not if theads are ordered right
[18:18:09] <SWPadnos> I should race to the coffee pot
[18:18:29] <jmkasunich> the lag in the speed feedback from the vfd will actually help
[18:19:19] <BigJohnT> the vfd at-speed should be false until it is running and at speed but I get a blip so my code is wrong I think
[18:19:36] <jmkasunich> oh, this is happening when the VFD first starts?
[18:19:40] <jmkasunich> I thought it was on a speed change
[18:20:15] <BigJohnT> I just proved it by putting a one second pause before the move
[18:20:29] <BigJohnT> the move waited till I got the at-speed from the drive
[18:21:15] <BigJohnT> before the move but after the s1220 m3
[18:22:48] <BigJohnT> I guess there is a moment when the commaned freq and the actual freq are still at 0 so that makes the freq diff 0 which makes the bool true...
[18:25:38] <jmkasunich> probably just need to re-order a line or two
[18:26:00] <jmkasunich> set frequency command, then set drive on, then calc freq diff
[18:26:16] <BigJohnT> ok, let me see what I can come up with
[18:26:51] <SWPadnos> there's already some logic to detect direction and enable changes - just don't do the at-speed calc in the same cycle that a change is detected
[18:28:11] <BigJohnT> I have it in read_data...
[18:28:23] <jmkasunich> hmm, sun is out, temp is over 36
[18:28:30] <jmkasunich> must go for a hike - bbl
[18:29:54] <BigJohnT> I added && *(hal_data_block->freq_cmd)>1 into the logic and now it works :)
[18:30:16] <SWPadnos> absolute values ... :)
[18:31:16] <jepler> so you can't use at-speed to determine if the spindle is now stopped?
[18:31:48] <BigJohnT> no, so far only to see if the spindle is up to commaned speed
[18:32:03] <BigJohnT> commanded
[18:32:53] <BigJohnT> right now I'm using spindle-on as part of the if so as soon as it drops out the at-speed drops out...
[18:34:03] <BigJohnT> probably 27 better ways to skin this cat...
[18:34:33] <BigJohnT> I could add a spindle-stopped pin...
[18:35:54] <SWPadnos> I think it's best to have at-speed be true whenever the commanded and actual speeds are the same, and the spindle is expected to be on
[18:36:07] <SWPadnos> that also accounts for a commanded speed of 0
[18:36:27] <SWPadnos> (which theoretically should leave spindle-on active but the speed at 0, but I think it doesn't work that way)
[18:37:50] <BigJohnT> what I have now would not work that way as commaned speed must be more than 1...
[18:38:53] <BigJohnT> I think the problem is the delay between the spindle on command and the drive reporting back the commaned and actual Hz
[18:39:27] <BigJohnT> it sees a spindle on and 0 and 0 for a diff of 0...
[18:40:34] <BigJohnT> maybe test for a speed change of any type?
[18:40:41] <BigJohnT> thinking out loud
[18:40:54] <SWPadnos> commanded speed could be 0.5
[18:41:20] <SWPadnos> there's no enforcement of an integer speed (unless the output is actually an integer instead of a float)
[18:41:59] <BigJohnT> I mostly put that in to confirm the racetrack contitions between the drive and HAL
[18:42:29] <SWPadnos> yep
[18:42:34] <BigJohnT> and HAL won the race every time
[18:42:45] <SWPadnos> yep :)
[18:44:23] <BigJohnT> SWPadnos: did you mean move this hal_ready(hal_comp_id); to just above the while loop?
[18:44:34] <SWPadnos> yes
[18:44:36] <SWPadnos> below all the inits
[18:44:47] <BigJohnT> k
[18:44:55] <SWPadnos> above "//here's the meat of the program .."
[18:45:12] <BigJohnT> yep got it
[18:45:24] <SWPadnos> thanks. I just noticed that during a previous conversation
[18:47:13] <BigJohnT> maybe I need to add hal_float_t old_freq_cmd; to see if the freq cmd changed instead of the >1 mess
[18:47:26] <BigJohnT> and add the logic to update it...
[18:48:43] <SWPadnos> that's chancy with floats
[18:49:07] <BigJohnT> yep
[18:49:15] <SWPadnos> in CSS mode, the spindle speed is recalculated often, and a single bit change could happen a lot
[18:50:49] <BigJohnT> I should add the speed-tolerance back in like I had it before to account for that
[18:51:26] <jepler> I think it'll turn out jmkasunich is right and the "at speed" calculation has to be realtime
[18:51:38] <jepler> so trying to make a sophisticated check in the gs2 driver may not be the place to spend one's time
[18:52:27] <jepler> bbl
[19:28:24] <KimK_> KimK_ is now known as KimK
[19:29:21] <micges> http://www.pastebin.ca/1299128 - emctaskmain cleanup for better understanding (very complicated now) emc2 code
[19:29:59] <micges> (if someone have time to look into)
[19:31:27] <BigJohnT> dang that compiler is picky it wants a ; everywhere one is supposed to be :)
[19:40:34] <BigJohnT> * BigJohnT likes comments in code even if they take time to put there
[19:41:54] <jepler> micges: does that just re-order the file?
[19:42:56] <micges> yes, like in jmk does in homing.c
[19:44:32] <jepler> micges: did you get a chance to test the second version patch for that "wrong velocity" bug?
[19:45:30] <micges> second version ? I have tested the one you liked on your sandpile
[19:45:38] <micges> with hal_get_period or so
[19:46:09] <micges> I've tested it and velocity is correct up to 0.0001
[19:46:15] <jepler> https://sourceforge.net/tracker/index.php?func=detail&aid=2478266&group_id=6744&atid=106744
[19:46:30] <jepler> attachment sane-periods-take2.patch
https://sourceforge.net/tracker/download.php?group_id=6744&atid=106744&file_id=307543&aid=2478266
[19:46:42] <jepler> (undo first patch before applying)
[19:47:35] <micges> of real machine I can test it on monday, on my setup for a moment
[19:48:09] <jepler> "take2" is the one I'd rather apply, it fixes some other ways you can misconfigure emc that aren't handled by the first one
[19:50:43] <micges> oh it change calculation period if was changed ?
[19:50:51] <micges> check in every loop ?
[19:51:26] <jepler> yes, that's a fairly accurate summary
[19:51:43] <jepler> in all real-world situations, the calculation will be done only once on the first invocation of the function
[19:52:06] <micges> yes
[19:52:08] <jepler> one situation which this gets right is the one where the integrator puts the motion function on a different thread than servo-thread
[19:52:41] <micges> how to apply ?
[19:52:56] <micges> patch?
[19:52:58] <alex_joni> man patch / look for reverse
[19:53:44] <alex_joni> to unapply the last one
[19:53:50] <alex_joni> then use patch to apply the new one
[19:53:57] <jepler> as for patches that only re-order things: I think they're a lot like running indent, which we discourage. That obscures the history of the file for tools like 'cvs annotate', and makes it harder to adapt a change from one branch to another (where indent has been run on one and not the other)
[19:58:10] <alex_joni> how about splitting it up?
[19:59:03] <jepler> same imo
[19:59:20] <jepler> if it helps with actual planned work, then doing it as a step may sometimes make sense
[19:59:40] <jepler> doing it for no specific reason is something I don't want to see
[20:04:53] <micges> jepler: this was before try to add running from line (own version), try to add different jogging area than in auto/mdi mode
[20:10:11] <micges> bbl
[21:19:06] <cradek> I'm with jepler on this (unsurprisingly) - all you will accomplish is to add bugs. I'm all for a big simplification (aka rewrite), though. Then the bugs you will introduce are for a reason.
[21:21:40] <alex_joni> cradek: but probably not for 2.3
[21:22:49] <cradek> alex_joni: if someone wanted to work on it today, it would probably be best to put it on a branch
[21:23:52] <cradek> speaking of bad ideas, that reminds me: in a local branch I've changed all the motion-causing canon calls to have a line number argument. this is the way I picture handling the readahead/queueing necessary for concave corner cutter comp. am I missing a more obvious way or is that it?
[21:25:59] <cradek> right now, I think task keeps track of the line number it just fed to the interp, and any canon calls resulting are assumed to be because of that line of gcode. I'm going to have to break that assumption.
[21:32:46] <micges> I'm also for a simplification
[21:35:02] <micges> wrong is also that if I want to enable/disable feed override flag I must issue gcode to the interp to do that
[23:22:52] <CIA-1> EMC: 03cradek 07concave_comp2 * 10emc2/src/emc/sai/saicanon.cc:
[23:22:52] <CIA-1> EMC: in the block, keep track of the N number and real line number both. send line
[23:22:52] <CIA-1> EMC: number along with motion-causing canon calls because the old assumption that
[23:22:52] <CIA-1> EMC: canons being issued come from the most-recently-read line is no longer true.
[23:22:52] <CIA-1> EMC: 03cradek 07concave_comp2 * 10emc2/src/emc/task/emccanon.cc:
[23:22:54] <CIA-1> EMC: in the block, keep track of the N number and real line number both. send line
[23:22:56] <CIA-1> EMC: number along with motion-causing canon calls because the old assumption that
[23:22:58] <CIA-1> EMC: canons being issued come from the most-recently-read line is no longer true.
[23:23:00] <CIA-1> EMC: 03cradek 07concave_comp2 * 10emc2/src/emc/rs274ngc/ (9 files):
[23:23:02] <CIA-1> EMC: in the block, keep track of the N number and real line number both. send line
[23:23:04] <CIA-1> EMC: number along with motion-causing canon calls because the old assumption that
[23:23:06] <CIA-1> EMC: canons being issued come from the most-recently-read line is no longer true.
[23:23:08] <CIA-1> EMC: 03cradek 07concave_comp2 * 10emc2/src/emc/canterp/canterp.cc:
[23:23:10] <CIA-1> EMC: in the block, keep track of the N number and real line number both. send line
[23:23:12] <CIA-1> EMC: number along with motion-causing canon calls because the old assumption that
[23:23:41] <CIA-1> EMC: canons being issued come from the most-recently-read line is no longer true.
[23:23:41] <CIA-1> EMC: 03cradek 07concave_comp2 * 10emc2/src/emc/nml_intf/ (interpl.hh interpl.cc canon.hh):
[23:23:41] <CIA-1> EMC: in the block, keep track of the N number and real line number both. send line
[23:23:41] <CIA-1> EMC: number along with motion-causing canon calls because the old assumption that
[23:23:42] <CIA-1> EMC: canons being issued come from the most-recently-read line is no longer true.
[23:25:20] <cradek> whee
[23:25:23] <cradek> http://timeguy.com/cradek-files/emc/correct-seq-numbers.png
[23:30:13] <micges> good night all
[23:39:37] <jepler> cradek: neat, it's good to see progress on this again
[23:39:54] <cradek> thanks
[23:39:59] <cradek> I hope I'm doing it right
[23:40:38] <cradek> anyway, now it's at least 80% done!
[23:42:20] <skunkworks_> Nice work!
[23:48:43] <cradek> I think everything involving 'the layers of crap' is done. now 'all' I have to do is add a type to the queue for each thing I want to allow in a concave corner and queue it when necessary.
[23:49:31] <cradek> if there are things it's easier (and acceptable) to just not allow, I have to error in those cases
[23:51:59] <cradek> bbl
