#emc-devel | Logs for 2010-03-05

[07:00:22] <ries_> ries_ is now known as ries
[19:31:41] <micges> jepler: m67 patch revised: http://filebin.ca/xqbsoh/m67.patch
[19:50:26] <jepler> the function name tpToggleAIOs doesn't make much sense, does it..
[19:50:37] <jepler> the rtapi_print call in tpSetAout should probably be removed
[19:57:05] <micges> http://filebin.ca/ncqbs/m67_v2.patch
[20:00:17] <jepler> and this wrong comment remains unchanged
[20:00:17] <jepler> } else { // we put it on the TP queue, warning: only room for one in there, any new ones will overwrite
[20:01:23] <micges> how it's wrong?
[20:02:16] <jepler> 17:12:47 <jepler> apparently it's an error in this implementation to set more than one aio before a given
[20:02:19] <jepler> move. however, the error is not diagnosed.
[20:02:20] <jepler> 17:17:02 <micges> multily m67 before move also works
[20:03:07] <jepler> I understand the comment to say that if there are two M67s for different outputs between moves, only one of them has an effect
[20:03:15] <jepler> what do you understand the comment to mean?
[20:04:05] <micges> the same
[20:05:23] <jepler> does that accurately describe the code once this patch is made?
[20:06:33] <jepler> I thought it was inaccurate, and that M67 E0 Q0 / M67 E1 Q0 / G1 Z.1 would set outputs 0 and 1 both when the G1 Z.1 motion started
[20:09:52] <micges> should be ok now: http://filebin.ca/zhzcyp/m67_v3.patch
[20:10:39] <micges> I had hard times with comment in emc source :)
[20:12:04] <jepler> if the comments are accurate they are more useful :-/
[20:14:10] <micges> I agree
[20:15:55] <jepler> hm
[20:16:05] <jepler> m67e999q0 is accepted
[20:17:01] <micges> should report error..
[20:18:24] <jepler> doesn't report error: m67e999999999q0
[20:18:34] <jepler> does report error: m67e9999999999q0
[20:19:27] <jepler> well, something to work on in the future :-/
[20:20:14] <micges> hold on
[20:26:43] <micges> err there is no easy fix for this
[20:27:28] <jepler> is there a possiblity of a crash (out of range memory access) for these bad values, or just gcode errors that pass silently?
[20:27:58] <jepler> and does the patch we're discussing change that at all?
[20:28:09] <micges> but I'll work on this, I'm using plenty of M62-68
[20:32:19] <micges> jepler: as you said that we will increase range of fixes applied to v2.4 branch can I add this to 2.4.1? will work more on this code and M66 error in mean time
[20:34:39] <jepler> so this is something you or your users will be using?
[20:41:46] <micges> yeah for laser engraving
[20:43:00] <jepler> go ahead and put it on v2.4_branch
[20:44:18] <micges> jepler: I will again carefully trace this code and add proper error checking tomorrow ok? I'm not trust myself today :)
[20:45:50] <micges> * micges take some rest
[20:46:31] <jepler> OK, let me know when it's ready for review
[20:47:25] <jepler> it seems like this change and the fixing of the interpreter error handling should probably be two separate commits
[20:48:01] <jepler> unless I'm very mistaken, the error handling is in different files and exists before now (while sync aio is doing nothing)
[23:19:37] <seb_kuzminsky> the hm2 firmwares got removed from emc2.git between 2.3 and 2.4, we should add a blurb about that to the update instructions <http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UPDATING#Changes_between_2_3_x_and_2_4_x>
[23:19:48] <seb_kuzminsky> jepler: should i just point people to your blog-entry?