[884] not sure I have a lot to say this week, been busy on other things [886] mainly windows things sadly [891] but, its given me lots of ideas as to how Id like to play with the emc gui [892] not a total loss then [893] no, the 'other' cnc app whose name we ddo not mention [894] there are one or two good ideas we can use [897] speaking of that, how does it stack up against emc? [898] user freindliness, way ahead [899] robustness, less so [901] and its closed source [904] so getting at bits to tweak them is impossible [905] (eg I am unable to add my corner speed compensation algos) [906] these algos something in the TP? [907] yep [908] sounds like the same prob les is working on [911] as material thickness increases, you slow down in G2/3 moves on a plasma [912] down to 0.5 times feedrate when radius = thickness [913] g1 = straight line, g2/3 = curves? [914] and 1.0 x feedrate at radius = 10 * thickness [915] right [918] but installation is a doddle, just click install .. job done [919] what about g1, followed by another g1 at 90 degrees - is that a zero radius turn [920] youd do an exact stop at the corner [921] I see [922] you cant comparre windows and linux installs though ... [925] chalk and cheese [926] users will compare them anyway [927] hence the value of BDI [928] yeah ... [929] maybe if we packaged a kernel rpm, rcslib rpm, emc rpm ... [932] rpm and deb installs are pretty much point'n'go affairs. [933] sure ... [934] synaptic is a great tool too. [935] as long as you have all the right dependencies [936] yeah, dependencies can be hell, [939] we could/should maintain 'sets' for RH7.x, debian testing etc [940] one day we might I guess [941] I think the only way a binary (rpm) install would work is if the environment is known... [942] apt looks after the deps prob. [943] it does, [946] but you still need to make the packages available in the first place [947] anyway ... installs aside [950] the two features that do seem to be plus points and we should consider perhaps ... [953] 1) the GUI is built onthe fly from a config file [954] (there is even a handy design tool so users can drag and drop their own GUI's [956] that I can probably summon up the enthusiasm to do [957] and 2) [960] user defineable macros [961] A number of drag'n'drop design tools already exist for linux. [962] so you can write yor own macro functions for M1067 or whatever and then bind it to a button in the GUI [963] to a GUI button? [964] that combination adds up to a *very* powerful customisation tool [967] yeah, a GUI button can be set to call a macro, its an easy way of seperating out the code [968] so you might write a macro to make a hole pattern, then there will be a "hole pattern" button on your GUI? [969] if you wishm yes [970] pops up a dialog box, enter radius and number of holes [971] interactive macros? wow... [974] the downside is its windows, and therefore sucky [975] what language to you write macros in? [976] sounds like some of the Conversational macros that were worked on a few years ago. [977] try not to hurl now ... [978] VB Script [981] looks for a bucket [982] so macros are really for programmers, not machinists [983] depends how deep you want to go ... [984] I thought macros would be written in G-code (of course, then they can't pop up dialogs) [985] they are for customisers and integrators [988] shure, you can put gcode in them if you want .. [989] code "GO Z20" [990] or [991] you can put G-code in them, but you gotta know VB to do it, right? [992] the code( string ) call does that ... [995] even a machinist could do that [996] we talked about macros at emc monday last year, unfortunately I don't remember much of it... they were definitely something people want [997] overall it is very powerful, and coupled with the user GUI thing [998] but I thought they were simply strings of g-code that could be called with m-codes [999] eg, I put in a 'park' button that calls M101 [1002] M101 reads the X and Y DRO's [1003] retracts the torch [1004] works out which is the nearest edge [1005] goes there [1006] and then traverses to the back of the machine off the sheet, to avoid hitting parts [1009] that is powerfull [1010] and .. I was able to code that without touching the source [1011] (which obviously I dont have_ [1012] I thought you said that the M code "pushes" the button - now it sounds like the opposite - the button emits the M101? [1013] right [1016] so M101 in the g-code program would park the torch without any gui button? [1017] yep [1018] or the button triggers an M101 [1019] that would be easy enough to implement in the EMC gui [1020] the M code call anyway [1023] so really two separate things - the ability to make M101 run a VB script, and the ability to generate an M101 from a GUI button [1024] yep ... [1025] the first is the major step [1026] yes, [1027] the second could be done today by giving the M101 in MDI mode, couldn't it? [1030] and we wouldnt use vb script either [1031] yes, pretty much [1032] buttons are obviously more user friendly [1033] but the gui built from a config file is the other part [1034] I'm all in favour of using other peoples good ideas :) [1037] what language would you use for macros? [1039] if it was down to me, Perl [1040] but ... [1041] I suspect tcl may be simpler to attach to emc [1044] what are the relative numbers of perl users, vs. vb users, vs g-code users, in our target audience? [1045] shrug ... [1046] we couldnt use vb anyway [1047] not suggesting vb ;-) [1048] and gcode doesnt have the syntax to do all we might need [1051] eg loops, conditionals, arrays [1052] just suggesting that integrators aren't programmers, and "programming" languates may not be in their skillset [1053] hmm, integrators will have some programming ability [1054] machinists might not [1055] or wont . [1058] a machinist should not have to see anything other than gcode [1059] but integrators .. [1060] fair game I say [1061] then why not C? [1062] compiled, not a scripting language [1065] it's as close to a universal programming language as there is [1066] mmmm ... [1067] strict typing etc? [1068] it needs to be simple I suspect [1069] I wasn't thinking about language attributes, just number of people familiar with the language [1072] I agree that C is too complex [1073] C is still the domain of hardcore programmers [1074] basic is the other "generic, well known" language [1075] something simpler and less rigorous is needed for the middle ground I think [1076] yeah ... [1079] VB is a good choice on that count [1080] (apart from the fact it sucks) [1081] Perl is more "modern", but I really don't know how well known by non-unix types [1082] logo ? [1086] not heard of it [1087] a language devised to introduce 7-yr olds to computers [1088] anyway ... [1089] oh OK [1090] those little turtle bots used in many schools [1093] (basic is for 10-yr olds) [1094] anyway ... the power of these things when combined is fairly much a killer app [1095] is there a gpl basic interpreter (the non-visial variety)? [1096] several [1097] what about a non-visual basic as a scripting language? or do we want/need the ability to pop up dialogs? [1100] I'm happy to look at how I can make my GUI thing build itself from a config file, or even look at the drag and drop tools around [1101] mmm, dialogue popup is not a great advanatge [1102] I guess being able to pop up a message box, or a yes/no box would be sifficient [1103] ok then, keep the scripts in ascii, no visual crap [1104] umm VB Script is just ascii ... [1107] its a bit of a misnomer [1108] I thought you had to write it using a gui tool like and IDE? [1109] nah [1110] just notepad [1111] oops, like an IDE [1114] VB Script is VB with all the design crap thrown away [1115] shows how much I know about it [1116] its just normal basic in effect [1117] (i only found this out this week) [1118] then why is it so evil (besides the M$ connection) [1121] because ... its basic [1122] basic = evil? [1123] shudder [1124] ok its not that evil ... [1125] but I am loathed to enjoy anything on M$ for religious reasons [1128] we could use bash ;-) [1129] bwbasic & yabasic are two to look at.. [1130] OK, [1131] hmmm... bash with NML hooks... [1132] so ... lets not panic about it too much now, but add it to our 'possible developments shoudl we actually get the thing running' list :) [1135] anyway, I agree that it is a powerfull thing, and we should try to do it... [1136] macros were already on the list, and this seems like a cool way to do them [1137] ok [1138] bash would really hurt the head of anyone not familiar with it [1139] I'm viewing my time using the 'other; software as a good opportunity to see what good things can be learnt from it .. [1142] yep [1143] it has some bad points ... [1144] enexplained crashes, odd behaviour [1145] IOW, it's a windows app [1146] yep .. [1149] step/dir only, right? [1150] and if you do want to change something deeper, you are fuxxored until Art implements it [1151] yep, spte/dir only [1152] and G2003, obviously [1153] which is step/dir at thened of the day [1156] close source only matters to us (and emc is effectively closed until it can be compiled easliy by a mere mortal and is better documented) [1157] so serious machine users will still want real servos ... [1158] nods at jmk [1159] have you heard of a CNC manufacturer called Larken CNC ? [1160] nope [1163] they are a US outfit, make a range of routers ... [1164] without wishing to turn this into Mach2 appreciation hour ... [1165] http://www.shopcamrouters.com/products_software.htm [1166] shows what theymanaged to do with the screen designer tools [1167] "know thy enemy" - nothing wrong (and alot right) with looking at them [1170] absolutely [1171] and not even an enemy, just anopther bunch doing the same thing a different way [1172] you could do that in tkemc, but you'd have to be about 15 and spend 24/7 hours fidding with geeky linux stuff to do so... [1173] poetic license [1174] nods [1177] you can do all that drag and drop, no user hard-thinking required ... if we could do that ... [1178] (and we can) [1179] not me - that stuff hurts my brain [1180] I'll write device drivers ;-) [1181] I was even wondering if we could use the same config files, its only CSV [1184] then we could benefit from the same toolset :) [1185] blasphemey! [1186] shrug [1187] toolset runs under win, right? and art owns it? he won't like that [1188] shrug ... [1191] its a free download ... [1192] whatver .. we can write our own [1193] the ui designer is a free download? [1194] how long do you think it will stay free it we start using it? it will be available to mach2 owners only [1195] yep [1198] I'll ask John Prentice (who wrote the screen designer) when I see him [1199] hes in Nottingham, just up the road [1200] so it's _not_ Art's code? that might change things [1201] shrug ... [1202] dunno [1205] I have no great love of windows [1206] if there is a linux draggy droppy tool, id ue that [1207] but users/integrators? [1208] qtdesigner? [1209] could be ... [1212] I do like that [1213] its a bit heavy though ... [1214] but it is nice [1215] a tool that runs on the same box as emc would be best [1216] ndos [1219] QT desinger runs everywhere [1220] so not windows, not because we hate it, because linux is easier for the user/integrator [1221] possibly ... but say we actually get this mainstream [1222] http://doc.trolltech.com/2.3/designer.html [1223] say people actulaly begin to use it more in production enviromnts ... [1226] humm isnt it tkemc tho? [1227] I can see the linux boxes on the routers/mills etc [1228] you want them to design the GUI on a win box, then just d/l it to the linux machine control? [1229] and integrators bashing out screens on PC;s in the office ... [1230] why not? [1233] so they would remain windows users, only know enough linux to run the machine... [1234] make the window manager fvwm95 and they are all happy. [1235] slaps picnet [1236] jmkasunich: sure ... get them in the easy way ... [1237] hey Robin started it ! Blasphemey! Blasphemey! [1240] jmkasunich: then let the linux religion work away at their brains [1241] then we become another fanuc - machine control is a black box [1242] not quite ... [1243] its a black box if you want it to be, but the lid opens and the sides come off too, if you want [1244] just like a car [1247] right - but _nobody_ except us will ever open it... [1248] wrong ... [1249] you read the dev list? [1250] us = emc developers and linux geeks [1251] joe machinist, or even joe integrator, will be content to use it as a black box [1254] (I'm not sure there's anything wrong with that...) [1255] what about those mails that come in occasionally 'we're running a 6 axis laser shoe leather cutting machine on EMC and want to modify the trajectory planner' [1256] some people do look under the lid ... [1257] and so long as you *can* look under the lid thats fine by me [1261] you can look under the lid now, but its a mess :) [1262] true... and to be honest, when's the last time you looked under the lid of mozilla... [1487] Question - How long is this Hackfest going to last ? [1488] My understanding last week was monday thru wednesday [1489] Late Wednesday ? [1492] probably [1493] I didn't hear specifics [1494] So book a flight out on Thursday... [1495] I think Smithy doesn't care - if folks wanted to stay until Fri that would be OK [1496] but I for one will have to get back home [1499] I'll probably leave around 5-6pm wed [1582] so what exactly did we decide today? [1583] user scriptable macros might be fun [1586] that's about it [1587] halscope is progressing and looks useful [1588] I still need to do the trigger stuff (right now I only have manual trigger) [1589] when will you be releasing that to the world jmkasunich? [1590] week, 2 weeks? [1593] but I'll do a commit of what I have within a day or so [1597] still has rcslib & emcsh to go through... [1600] but at least the remote GUI works. [1601] and I shall continue my thnkings on the gUI and may actually start beating the thing into shape [1602] Spent the afternoon looking up texts mentioned in the rcslib source code. [1603] some of the references are *very* dated [1604] much of it in Olde Englishe? [1607] Much talk of SysIII Unix