Hi John, This past week I did get a chance to try out the EMC2 checkout from last weekend on a real machine. how'd it go? Backplot works fine, troubles with real machine. This was a 1.3 GHz AMD known to run the hardware OK. There seemed to be some problem with the step generation. I looked around a bit at the setup but did not dig deep. "it blew a $1200 block of titanium" :D what kind of troubles? lost steps or something? I assume you were machining air, not titanium ;-) No, much more confused than that. Sometimes it would respond to jogs properly on one axis but mostly it would fail to set direction and lose more than 50% of the pulses. Just fouled the air a bit with my imaginary cutter. If you are inclined to do some coached testing, I can be back at the shop in about a half hour. certainly what ini file did you use? the emc.ini from CVS, unchanged? The default emc.ini from CVS matched my pinout so I used it. ok (if you had changed anything, I'd ask you to mail me the ini) btw, what drives are you using? I did look at some of the timing setup stuff in the HAL but didn't have enough time to really understand how HAL init worked. Drives are my PMDX-150 based on opto isolated, PIC controlled Allegro A3977 chips (like Xylotex). that ini file works with my xylotex drives, but they have no optos... so maybe it's a setup or hold issues that is configurable, we'll figure it out These drives are running well on same PC and mill under TurboCNC and Mach2. understood - the standard mach2 or Tcnc timings might be different than my standards, but mine can be configured as needed we can use halscope to look at the signals inside the pc I'm guessing you have a real scope to look at them outside? Yes, including a storage scope if things get sticky. we should be able to figure things out then I'll probably be online much of the day, just yell at me when you want to work on it OK, I'll start heading over there in a few minutes. LOGGER GAP Got one M on the ini file, lots of Ps. P means patched - that means changes from CVS were incorporated into your copies M means modified, you modified the ini file so that it differs from cvs How do I force a new virgin copy. first let's see what you changed cvs diff that will show the differences between your copy and cvs oh emc compiling fun .. I really must take up that hobby again soon ;) * jmkasunich throws things at robin Hope he threw something HEAVY! * robin_sz catches them and eatrs them ... Yes! Now I remember. Your velocity and accel was very slow and I tinkered. Lets get back to baseline and that will probably fix the following error. remember that velocity and accel are in inches/sec and inches/sec^2 the 1.2 I had in there corresponds to 72ipm not super fast, but not bad for a sherline class machine Something is funny then. I still want to get back to baseline. ok inches? ... are they the ones just over a metre long, or is that yards? Angstroms based on the speed of my machines response..... heh. those are the ones that are based on the length of the King of England's thumb ok steve - to get back to original there was someone on yesterday with very bad settings, IIRC, his max speed was 1700hz, but he was microstepping. rm the ini file, and do a cvs up thats like 60rpm emctest: got the old ini file now? Yep, clean compile running... today was the culmination of erm 6 months work, i have now mounted a pully on the end of a leadscrew - it is rocket science. picnet: HAHAHHA * sxpert_ has ordered pieces to build a star trek motorized pocket door... when you say it was slow, what were you doing? jogs? yes was the axis speed slider (just above the MDI entry box on the GUI) adjusted to a good speed? (for some reason it defaults to 1 ipm when TkEMC starts) John, thanks for the slider hint. Not being an EMC user, I did not know it affected jogs. afiak, it _only_ affects jogs Slider seems able to set reasonable speeds. Other problems back to original ones. I will experiment a bit as it seems to start OK with first move, then goes off track. what are the other problems? Saw failure of direction bit and tons of lost steps. Give me a minute to get reproducable failures. ok OK John, this is really going to be fun. If I do a clean start and only jog X, all is well. If you ever jog any other axis, things get weird, including further attempts to move X axis. more..... The direction may be set correctly, however the step rate for negative travel is extremely low, about one pulse per second. Positive travel remains normal, hence my thinking that direction bit was failing. this is after you jogged another axis? Worse, the once per second steps are still going.... probably a long buffer move not yet completed. First time I jog an axis other than X. let me get the facts straight... initially, x can be jogged _both_ positive and negative? Not always an immediate failure, but more than 50% of the time. you just said: If I do a clean start and only jog X, all is well. so is all well if you only jog X, or not? X will jog reliably in both directions so long as you do nothing else. If you then try any other axis, then X too will be corrupted. ok, so then as I said: initially, x can be jogged _both_ positive and negative? when you try to jog Y, does Y move? does X move too? how far? Sometimes Y or Z may jog OK if you do a clean start and only move just Y or just Z, but eventually it will fail even then. Have not seen cross axis problems, e.g. Y does not cause X to move. but once Y or Z has been jogged, then X doesn't jog correctly correct how fast is the box you are running? but not absolute, once in a while it still works (sorry) what you have there is what we call "a problem" Box is a 1.3 GHz AMD ok, open a shell and cd to your emc2 dir Same symptoms on 800 MHz Intel laptop bin/halmeter * jmkasunich fires up the compile farm so he can try it on a RC46 board once you have the halmeter up... click on select choose "parameters" tab scroll down and click on "motion-controller.time" and click the accept button the meter will display a number that is probably jittering around roughly what is the number? Wheeeeeee, this is fun. Number is mostly 4000, sometimes 3000. in the select dialog, click on motion-controller.tmax, and click selecxt I like HAL-Meter already. tmax is probably quite a bit higher than time was, right? maybe 6000-10000? but not insanely higher, like 1000000 OK response of command interface of HAL-Meter was sluggish this time. The number is now 50000 steady. ok time is the time needed to execute that last pass thru the RT control function tmax is the highest recorded time is your mouse sluggish? no (I've not seen halmeter get sluggish before) meter now seems ok ok take a look at motion-command-handler.tmax while I get my RC46 box going 20000 ok, quite reasonable * jmkasunich scratches his head the axis should not interact in any way in free mode (aka manual) still waiting for 200MHz RC46 box to start KDE two possibilities... 1) get out of emc2 proper and just make sure your motor control works (using only the hal stepgen modules) 2) assume the problem is inside emc2 and start looking at what it's telling the hal to do with the motors either, you lead.... first I'm gonna see if the same things happen to me (gotta do cvs up and build first) OK, I'll go make some coffee here.... hello HI les Just writing up a reply to one of Jon's posts about torque mode vs velocity mode in servo amps I was hoping to hear your take on this... He is kinda implying that one has to have an imbedded velocity loop for cnc Hi les. I'll have to disagree on this one I want to reference a paper on the subject at motionvillage but the site is down * jmkasunich_4 discovers a new bug... (sorry steve, not the one we're looking for) RC46 related? seems that if task tries to open rtapi shmem and fails, it keeps trying err, maybe it's the rtapi_init() call that it keeps retrying... in any case it has rtapi all screwed up I think I should have done a make clean, rather than a make - our dependency files aren't quite right I do a clean by default, but I have a faster machine.. gahhh - I hate KDE 3! Gnome ... its the one true way is gnome light and fast! its software silly, it doesnt weigh anything ..???? RC46 installs KDE 3.1.5 and it does feel a bit sluggish simply scrolling back in a shell window took nearly a minute! $#$!$#% ridiculous this is a 200MHz box, feels like 4.77 * jmkasunich_4 does ctrl-alt-F2 for the one true shell ok, I need to fix that, but that's not steve's problem while the make is making, let's apply logic emctest: if you unplug the parport connector and just watch the backplotter, does it work perfectly, or do strange things still happen? backplot continues normal response while step outputs are hosed ok, that narrows it down somewhat emc2 is running right now, right? (by running, I mean tkemc is on the screen) open a shell, cd to emc2, and do: bin/halcmd show >tmp.tmp then mail tmp.tmp to me so I can look at your hal configuration once that's in the mail, I can walk you thru a test of the stepgen module (without emc, just the stepgen) we can put the motors thru their paces that way what is the port address of your parallel port? default port of 378, hal config is on its way by email I hope. Damn fancy web pages that some browsers don't like.... ok you want a guided tour of hal and steppers? (we'll manually install stepgens and make your motors turn) OK, let's go for it ok, make sure emc2 is shut down (close tkemc) you'll need one shell, cd to emc2 bin/halcmd show should print a couple error messages (just checking to see if emc is truly shut down) ok? one, rtapi init failed two, shared mem right - msgs aren't important, I expected it to fail sudo scripts/realtime start should print nothing, just give you back a prompt bin/halcmd show my emc machine is logged in as root, so i'll skip the sudo ok this time the halcmd show should print some info "Loaded HAL Components:" and about 10-12 more lines contents uninportant right now as long as you didn't get error msg got using /lib........ to realtime start, forging ahead no errors ok /sbin/insmod rtlib/hal_parport.o cfg="0378" silent bin/halcmd show this time you should get a lot of output yep want the "tutorial" version, where I explain the output? or the "just get the darned motors moving" version? want to learn some, but not burden you too much not a problem bin/halcmd show comp there are several subcommands for show - show comp shows all installed hal components ok (show by itself runs them all, hence the long output) you can see two components listed - one is halcmd itself the other is the RT parallel port driver bin/halcmd show pin ok that shows the HAL pins - at this point, only ones exported by the parport driver show up bin/halcmd show param parameters - again only parport has exported any bin/halcmd show funct lists functions exported by the parport driver. ok, now lets install another component - the step generator ok /sbin/insmod rtlib/stepgen.o cfg="0 0" period=50000 fp_period=1000000 if you do "bin/halcmd show pin" again, you'll note some more pins added, that begin with stepgen.xxx likewise with params and functs you can think of these insmod commands as placing ICs on a board we need one more module a signal generator /sbin/insmod rtlib/siggen.o ok since this is for learning, we'll do one more module - the realtime part of halscope /sbin/insmod rtlib/scope_rt.o ok bin/halcmd show funct that is a list of all the realtime functions we have at our disposal but none of them are running yet bin/halcmd show thread that is a list of realtime threads that we can use to execute the functions ok first we'll set up the 50uS thread things we want to do at that rate: read the parport, generate step pulses, write the parport was it OK that two threads already existed? they were created when we insmoded the stepgen module, thanks to the "period" and "fp_period" arguements on the insmod line ok the periods are in ns, so we have one that is ~ 1mS and one that is ~50uS 50uS first bin/halcmd addf parport.0.read stepgen.thread ok that means "add function (addf) parport.0.read (the function that reads the parport) to thread stepgen.thread (the 50uS thread)" bin/halcmd show thread note that the function now appears under the thread ok, see structure now we add two more functs bin/halcmd addf stepgen.make_pulses stepgen.thread bin/halcmd addf parport.0.write stepgen.thread ok now the 1mS thread bin/halcmd addf siggen.0.update stepgen.threadFP (siggen is a "wavetek" type signal generator, makes sine, square, triangle waves ok bin/halcmd addf stepgen.capture_position stepgen.threadFP bin/halcmd addf stepgen.update_freq stepgen.threadFP bin/halcmd show thread we've now constructed a list of functions that can be executed in realtime, at the specified periods bin/halcmd start ok bin/halmeter & note the & - that makes it start but give you your prompt back if you forget the &, the prompt won't come back, you'll have to exit from halmeter to get the prompt ok do it again to open another meter (they're cheaper than flukes, you can cover the bench with them if you want) then click on one of the meter's "select" button scroll down in the pins list, click on siggen.0.triangle, then click OK you should see a rapidly moving number ok by default it's a triangle going from +1 to -1 and back a 1Hz let's change the freq leave the meters there, go back to the shell window bin/halcmd setp siggen.0.frequency 0.1 that means "set parameter (setp) siggen.0.frequency to 0.1" note the number displayed by the meter is moving slower now moves slower, update rate same right - update rate is determined by the meter - the actual signal is being modified every 1mS (because siggen.0.update is in the 1mS thread) now let's fire up the scope bin/halscope & note the & again now where did I put my 19" screen??? you can drag the meters off into a corner somewhere, they're little and the "realtime functiuon not linked" dialog won't be there long the main scope window is the one labeled "HAL Oscilliscope" in the "realtime function not linked" dialog, click on "stepgen.thread" leave the multiplier at 1 and record length at 4047 click OK ok bottom left of the scope, just above "selected channel", click on 1 this is just like the meter dialog - you pick what you want to look at scroll down do siggen.0.sine, click it then click 2 on the scope, and select siggen.0.cosine ok upper right - Run Mode, click normal Trigger, click auto top center, note that timebase is 50mS/div hard to see a 0.1Hz signal at that speed but you should be able to see what is going on, both signals are going up and down, one leading the other by 90 deg ok so far we've only been looking at the siggen now we want to connect it's output to a step generator input bin/halcmd show pin the stepgen pin we want to drive is called stepgen.0.position-cmd you don't connect pins directly to each other HAL works like a schematic netlist - pins are connected to nets (hal uses the name "signals") so lets make a signal function names use underscore and pin names use hyphen? hyphen and underscore are legal in both kinds of names I should go back in and make the naming conventions more consistent ok bin/halcmd newsig X-position float ok that means "create a new signal (newsig) called X-position, that handles floating point data bin/halcmd show sig now to hook it to the signal generator bin/halcmd linksp X-position siggen.0.cosine means "link signal X-position to pin siggen.0.cosine", there is also a linkps, which links pin to signal... they do exactly the same, but in a ini file, one might be easier to read than the other bin/halcmd show sig note the signal name is now below the pin name, with an arrow to show that the pin is driving the signal note the value is also non-zero ok if you go to one of your meters and click select, then click the signals tab, you'll see the signal there - you can monitor signals just like pins (same in scope) now lets hook that to a stepgen bin/halcmd linksp X-position stepgen.0.position-cmd pause..... hooked HALMeter<2> to X-position and it is not reading anything, still shows -------- hmmm try hooking it to a pin, say siggen.0.sine that works try going back to the signal now fails with ----? yes, uninitialized readout I suspect I think I know what is happening. when you click on the signals tab, Xposition is already highlighted but you _must_ still click on it, before clicking OK bingo if there was more than one name there, you would click on one, but with only, and it's already highlighted.... I wish I could make the dialog open with nothing selected fyi, squarewave pin is hung at solid 1 are you sure, or is it clicking from 1 to -1 oops, didn't look long enough been there, done that when debugging siggen... don't want to admit how much troubleshooting I did before I noticed could you put an _null in all lists maybe meter is due for a rewrite once emc2 itself is working better ok, back to the last command which I have not yet entered eliminate the scientific notation (unless values are very big or small), add a "bar graph" below the numbers, etc bin/halcmd linksp X-position stepgen.0.position-cmd ok to make the scope more usefull, let's change from 0.1 hz to 5 hz bin/halcmd setp siggen.0.frequency 5 ok if the scope is still running, you should see sine and cosine if it's not running, click Normal in the RunMode box well, not quite..... red is sine or cosine, but green is solid +1 what is displayed at "selected channel" below the screen? probably 2 and siggen.0.cosine? yes, and will track my click on numbers above... no effect on display green and red swap when you click on 1 and 2, right? 2 is the flat one? (all channels are red, except the selected one, that's green) they swap, flat is green when 2 is clicked ok, with 2 clicked, click on the long button under SelectedChannel that will bring up the source dialog, click on siggen.0.cosine again, see if that fixes it I need to look into that oh, when you do that, the scope will stop it stops on any change of channel click on RunMode Normal to restart ok, running ok again both signals are good now yes ok, click on 3 and select stepgen.0.step then click on 4 and select stepgen.0.dir then RunMode Normal looks like what i expect ok the vertical controls (under run mode) affect the selected channel you might want to scale step and dir smaller and move them up or down to uncover the sines before we go further, let's also set up triggering pause the vertical offset jumped to bottom of screen on first click, now cannot move, no arrows or slider on "pos" button hmmm window size problem..... I've been following along on my TNG box, perhaps I should switch over to RC46 and catch up the gui may work differently there problem resolved by just making scope window larger slider had no room to move ok ok, triggering far right, bottom source button select sine as the source set trigger back to normal, runmode normal zoom in a little using the horizontal zoom, above screen note the bobbles on dir - I'm looking into that - may need to adjust the deadband that's built into stepgen fine tuning stepgen could be fun stepgen is pre-tuned (once I fix that bobble) we could have done the same thing using a PID block and freqgen referring to code not response ok sampled system in a continious time world just like before with the sine and cosine, the step and dir signals aren't going anywhere time to connect them to the parport well, first we need to make the signals bin/halcmd newsig Xstep bit bin/halcmd newsig Xdir bit now we connect dir bin/halcmd linksp Xdir stepgen.0.dir which parport pin is dir for you? 2 or 3? as in default ini, not Xylotex dir is 2 bin/halcmd linksp Xdir parport.0.pin-02-out isnt it a good idea to have inductive sensors for stop? err hard stops ? depends on the machine since they are contactless.. limit switches are good but many small machines do not have them mine dosent yet :( inductive can have problems with ferrous metal chips small machines with weak motor don't bother with any kind of switch or sensor, they just run into the physical limits of the machine but I feel fear anytime I am close to the edge.. :) hello guys hi alex welcome, we are busy baking an EMC2 cake nice ;) more like a HAL cake right now hi john so dir should be coming out of the parport now step bin/halcmd linksp Xstep stepgen.0.step bin/halcmd linksp Xstep parport.0.pin-03-out I just came back from my trip, so unfortunately I didn't find time for the DRO driver steve: the default scaling for stepgen is 100 steps per length unit ok to hal cmds so since we are giving it a sinewave that swings from +1 to -1, the step sequence is stepping +/- 100 steps seems to run not much motion no, but sounds right should be safe to turn on the driver (or did you already) did it how many steps (u-steps) per rev on your motors? 8 microsteps, appx 2:1 timing belts, 3mm/rev screws let's lower the frequency and start increasing the amplitude bin/halcmd setp siggen.0.frequency 1 8usteps means 1600 steps /rev, we're doing +/- 100 step now, or about 1/8 rev of the motor shaft does that look about like what you're getting? 1/8 th looks about right lower freq running 1 cycle per second now, right? yes jmk: short question yes alex? about passing arguments to drivers I see it is a little different than emc1 a lot different I think everything get's sent through MODULE_PARM ? things needed at module loading time, yes I was interested in port address and maybe # of axes where get's the inifile get parsed? what kind of driver are you talking about? well I want to write one for DRO actually for my own board, but it's very similar to DRO your board is basically a set of encoder counters, right? yes but I need a BASE_ADDRESS defined in the ini, preferably that should probably be passed at insmod time, so it is a MODULE_PARM yes sure does it get parsed by emc.run? look at emc.ini in the emc2/configs directory in the hal section found it your module would be loaded by a line like RTMODn = alex_dro_driver and you could have a line like RTMODCFGn = base_addr=0x1234 that would pass the base addr those two lines get turned into: /sbin/insmod rtlib/alex_dro_driver base_addr=0x1234 by the run scripts insmod alex_dro_driver base_addr=0x1234? yes ;) I see now some xxx.hal defined in emc.ini where are those located? in the configs directory hmmm... don't find them on this machine, but it's an old cvs checkout I'll do a new one ok steve: next step would be to get another axis working ready need to create three more signals, Yposition, Ystep, and Ydir (using bin/halcmd newsig ) connect Yposition to siggen.0.sine, and to stepgen.1.position-cmd connect Ystep to stepgen.1.step and to the appropriate parport output same with Ydir you want the step by step? I am trying it now is there a "killsig"? delsig bin/halcmd with no arguments gives a help screen ok ok as in two motors wiggling now? yes, two motors moving, but with just the interactions I would have predicted based on EMC2 test results hmmm this hardware works OK with emc1? never tested emc1, just turbocnc and mach2 scope is not triggering any more runmode is normal? yes click the force button on the trigger menu does it trigger? once that's expected set trigger to auto auto runs source (bottom right) is chan 1? and chan 1 (click the 1 button) is siggen.0.sine? reselecting chan1 source fixed it, signal was flat line on scope I need to investigate that hopefully I can replicate it here another question with DRO: go ahead well...I've jsut been doing some thinking there is a case where: 1. the machine running emc is too slow so it outputs too few impulses I then used a gecko with PLL to increase the step-frequency but now there is a difference between the commanded pulses and the counted pulses through the DRO right? ? you are sending step pulses to a gecko yes it is multiplying them and turning the motor running a DC motor yes. on the motor I have an encoder oh, a gecko 340, not a stepper driver whose signals go to the gecko and to a DRO board exactly ok now... EMC sends out 10 pulses but the motor spins 100 pulses (gecko with 10x multiplier) right the DRO board reads 100 pulses right and everything get's confused I was thinkind about a small HAL component that does just prescaling is this emc1 or emc2? for now emc1 but I wanna run it later also through emc2 in emc1 I fixed it through the driver INPUT_SCALES & OUTPUT_SCALES = ?? well... couldn't figure OUTPUT_SCALES out right, input scale would be 10x (or 0.1x, can't remember) of output scale I have only seen OUTPUT_SCALES examples for -10/10V adjustments for servos but it's the same code, or should be I was wondering... if it wouldn't be better to make a HAL component that does prescaling hal and emc1 don't work together well... I am talking for emc2 now ok I got emc1 sorted out (not very nice, but it works) if you look at my software based encoder counter, you'll see that it has two outputs one is called "count" iirc, and is an integer the other is called "position" or position-fb or something like that, and is a float there is a parameter called position-scale or something like that, that sets the scaling I see so you should not need a prescaler, just set position-scale so the float output is correct ok... in this case ;) well then... I thought the count/position transformation is still in emcmot not in emc2 the motion module outputs position in length units as a float, and gets feedback in length units as a float so now it's possible that the encoder_board driver delivers besides counter also position all length <-> count scaling is done in the drivers (either stepgen or encoder) so only position get's used or.. DRO or other drivers that get written in the future hopefully all drivers that implemenet an encoder input would have the same interface on the hal side - raw counts and floating point position, with a parameter to set scaling well.. that could be made a demand some guidelines for writing drivers yeah... such guidelines are on my to-do list but you got there first ;-) ok... so, that I get it right I need to write a driver that: 1. get's it's BASE_ADDR, and axis_count through MODULE_PARM 2. implements raw counts, floating point pos, with parameter / axis 3. exports a function for reading the counters yeah if you look at src/hal/components/encoder.c, I was just reading there you could discard the "update_counters" function ( hal_export_function() call ) retval = hal_export_funct("encoder.update_counters", update, counter_array, 0, 0, comp_id); yes also discard the C function update() which does counting in SW the code to read your hardware would go in the C function called "capture" in place of: /* capture raw counts to latches */ *(cntr->count) = cntr->raw_count; /* capture raw counts to latches */ *(cntr->count) = cntr->raw_count; yes the Z-mask stuff is there to deal with index pulses... to be honest, I'm not sure if they're being handled properly right now or not and also I will discard zero-imp. well... my board doesn't handle zero-imp, and AFAIK DRO doesn't either that's ok emc2's motion controller can actually handle index pulses as normal digital inputs, routed directly to the motion controller nice so you could send A and B to your card, and Z thru a digital input to the motion module (for homing) actually it could also handle A and B directly to a driver, from parport if it's slow enough right - that's what my encoder driver does but a hardware board like your's is much faster and you use it like that? the idea is that on the HAL side both drivers look the same or you connect it to a siggen? I have an encoder with a handwheel on it as part of my test setup (I haven't done anything with servomotors yet) i see so many things to do, so little time ;-( always i wanted first to start using hal_skeleton but now reading through encoder... it's much more like what I need for making hal drivers, the best skeleton to use is something that is similar to the hardware device you will be driving yes if you were doing digital I/O, skeleton would be good ok.. so it will be called hal_xxx in src/hal/drivers right I think.... there is hal_parport in the same place yes, but that was a special case because parport might exist elsewhere on the system (standard linux driver for example) better in components ? no, it goes in drivers ok but you don't need a leading hal_ in front of the name, unless leaving it off is likely to cause confusion hal_parport was special because linux already has parport so if your board was called alex_dro, the driver could be src/hal/drivers/alex_dro.c OR /src/hal/drivers/hal_alex_dro.c your choice hal_alex_dro I think hal_ helps solving some confusions ok however, your pin names should be "alex_dro.0.position", not "hal_alex_dro.0.position" I called the board pc104 hope that doesn't confuse people it probably will, there are lots of pc104 boards well then it gets renamed pc104 is the form factor I know does the board have only encoder counters on it? or does it also have digital I/O, or DACs? only encoder counters in this version 4 axis max think in generic terms that's 4 counters, not 4 axis sorry you're right 4 counters max somebody might use it with 3 axis, and the 4th encoder on a lathe spindle for threading, etc sure I wonder how steve is doing? alex_joni: is this board something you've designed for your own use, or a potential product that you might sell? well... I want to sell it, not as a product but as a component in the final product ok, nothing wrong with that so the board itself can be used by others I can supply schematics & such steve is busy, hal scope results look correct, trying physical scope ok steve.... any questions just ask be aware that you can do bin/halcmd setp siggen.0.amplitude and bin/halcmd setp siggen.0.frequency if you'd like to change the signals going out have changed frequency, not effect on problem didn't neccessarily expect it to change the problem, but perhaps changing amp or freq might facilitate troubleshooting alex_joni: you mean the board design can be used by others? or do you mean that others could send you money and get a completed board? (either or both is good) I mean the board design can be used by others, although I still have to clear this one with a co-worker but in principle I think it will be ok didn't give it much thought that would be great, if the co-worker agrees essentially like GPL'ed hardware yes well.. I'll keep you posted maybe put up a little web-page for the board if I find the time ;) are you listed as an emc developer? not yet if so, once you are happy with the driver, and have a name that isn't likely to be confused with other boards, commit the driver do you want to be? (if not, I can commit your driver for you) well...I hope next week I have something finished or at least partly ok there is a reset pin in your encoder is it used at homing? no I designed that encoder module before I designed the homing algorithm maybe that pin will go away don't know yet so homing doesn't affect the position in the driver? it just remembers the offset? and substracts it furtheron? no, homing works by adding an offset to the feedback from the driver yes ok if you look at the EMC2_Code_Notes document, there is a drawing of how data flows thru the joint controller part of emc2, you can see where the offset is added to position command and the same offset is subtracted from feedback ok when in RT do I need iopl() ? don't think so or by using rtapi_inb it is used with privileges? in rt, you are running as a kernel module, so you already have privliges just use inb() and outb() not rtapi_inb() ? hey ray! Hi John. How you doing today? not bad found some subtle bugs in halscope :-( Bugs? How? halscope bug: under some circumstance (not sure exactly what yet) traces on the scope go flatline if you re-select that trace, it comes back I've not seen a flatline here but then I've not used it a lot. I'm pretty sure the "circumstances" that are involved include either adding new signals or linking things to signals.... both are normally done when emc2 starts Were you able to work through the motion.o problems from last week. * jmkasunich tries to remember which problems It was hanging alex's computer last sunday. rayh: me alex? or some other alex? I thought so. Were you trying to compile it? well... my computer was crashing, but not from motion.o but from rtai I moved from 24.1.13 to rtai 3.0, and now it works fine Oh. I must have been misreading. no problem ;) glad you remembered :) Good. I'm using 24.1.12 here. Seems to be fine. well.. it really is strange I have a second machine same setup, and it works but now that you point it out it is 24.1.12, and last week I was using 24.1.13 Oh really. maybe there's a problem in 13 ? OK, problem solved, time to go home, ain't never gonna tell, nope not gonna tell come on, fess up! some kind of inversion involving body parts that don't really fit IOW, a hardware issue? Yep, Mach2 supports a watchdog like feature called a "charge pump" and I forgot to disable it. It was picking up just enough crosstalk to work part of the time, then deciding occasionally to lock out motion. oops HAL is happily drawing endless sine/cosine circles. cool then it's should also work with emc2 it Now how do I shut HAL down so I can run EMC2. you can't - you machine is doomed to make circles forever... ;-) bin/halcmd stop serves me right will stop realtime execution jmkasunich: does the signal that flatlines on halscope continue to exist within hal? yeah, it seems to be strictly a scope issue steve: next step /sbin/rmmod stepgen /sbin/rmmod siggen /sbin/rmmod hal_parport /sbin/rmmod scope_rt scripts/realtime stop that should do it except the meters that caused Gtk to complain when I closed them steve: did the gtk messages cause problems? jmk: you could have used 2 siggen's to make some nicer graphics EMC2 seems to be running, jogs at least lissijoius? (or however you spell it..) lissajou I just looked it up ;) but yes that would be fun.. have to try it sometime There you go. Then you could use a parm to change the angle between each at the same freq. I used to play with that on scopes I ran the two signals just a bit different frequency and watched the pattern change. yep hmmmm. maybe I need to figure out how to do X-Y mode on halscope ;-) or not What kinds of signals might you want to plot xy? none, except to make pretty pictures is there a document that describes RS-274D? I've done a bit of searching and can only find references to the standard, not the standard it's self you probably have to buy the standard itself jmkasunich, I would do that, but ansi.org draws a blank EIA maybe? (as in RS-232, RS-488, etc) (my speciality is low level motion control, not the g-code language) I see bytecolor: you could read through the NGC controller there are most of the G-codes described RS274 is a standard that was never really finished. The NIST document on the Allen Bradley version is at http://www.isd.cme.nist.gov/personnel/kramer/pubs/RS274NGC_3.pdf the file is RS274NGC_3.pdf that's the one ;) I have the braindead CD installed on a PC in the garage... I'll look for that if my memory serves me well you could find this document on the CD ok, I was trying to write a simple parser with flex jmk: can I do a sscanf(argv[1], "%i", &PC104_BASE_ADDRESS) ? not in kernel space well.. not argv[1], but in the string from MODULE_PARM :( so I have to parse it manually MODULE_PARM doesn't need to be a string look at encoder.c again there are two module parameters num_chan is an int, period is a long insmod parses the command line for you and sets the variables so for an 0x300 declare PC104_BASE_ADDRESS as an int Well, the version of 3D_Chips that EMC2 cut in air looks very good. 8-) cool cool emctest, I have the undesireable duty of working with Allen Bradley controlled lathes at work I think I'll declare victory and go play with my new(used) backhoe. I _think_ insmod will even parse 0x300... Thanks for the tutorial and help John. you're welcome thanks for testing emc2 under RC46 alex_joni: do you have the linux device drivers book by alessandro rubini? Hex or decimal works with module params my RC46 box is too slow paul_c: thx the book covers module parms (and it is available online if you don't have the paper version) don't have the url handy, but google should find it orielly.com that book didnt get very favorable reviews at amazon, I was considering buying it I dunno what the amazon folks were thinking, IMHO it is _the_ resource for kernel module programming jmkasunich, yes, but like you said, it's online for free now, so I can decide for myself if I ever get around to it :) yep (I prefer the paper version, easier and faster) yes, me too, I've tried to read more than one ebook jmkasunich_4: A HAL Q. shoot Just where do the read and write functions get called in emcmot ? they don't they get added to a hal thread (as do motion_command_handler and motion_control) so you can control the order of execution from the ini or .hal file OK... I'll rephrase... How and where do the read/writes get called ? they get called by hal (dynamically linked) the first three lines of core_stepper.hal set up the step generators the first two lines of standard_pinout.hal set up the read and write of the parport and in the source code ? from hal_lib.c if you do "bin/halcmd show thread" while emc2 is running, you see the list of functions and the threads they are in hal_lib runs down that list calling functions thread_task() (line 1891 in hal_lib.c) does that jmk: it seems to compile rt-only for now but I do get a warning: __module_license defined but not used is your invocation of the MODULE_LICENSE macro wrapped in ifdefs as in encoder.c? yes #ifdef MODULE_LICENSE MODULE_LICENSE("GPL"); #endif /* MODULE_LICENSE */ then I'm mystified... the only thing that does is avoid a "tainted kernel" message when you insmod it that is straight out of the book anyways try commenting out that line and compile again, see if the warning goes away it goes away maybe strange kernel here, with SuSE modifications well it's definitely that macro then... don't know whats inside I also get a warning in /usr/src/linux/include/linux/module.h : __module_kernel_version defined but not used #ifndef MODULE #define MODULE #endif only if you also have: #ifndef RTAPI #error This is a realtime component only! #endif if you are trying to build a module that can be compiled for RT _and_ non-RT, it is more complicated i know for now just RT paul_c : no difference for your hardware, a non-rt driver doesn't make much sense, I think well.. I find a nonrt tool usefull to see if it's working the board I mean true alex_joni: a test... make a C file containing only this line: #include just to see if I move the encoders if the counters change halcmd shows up: ID Type Name 03 User halcmd and see what happens if you try to compile it 02 RT tiro is tiro the name of your module? yes ;) cool and I have 4 counts and 4 positions there is no 01? nope odd I did a scripts/realtime start and insmod tiro.o and insmod hal_tiro.o to be more precise just realized I don't have 01 either... I think 01 might be the hal lib itself could be ... beats me yes, it is hal_lib, silly me... do cat /proc/rtapi/modules RTAPI is a the realtime API that underlies HAL RTAPI calls are translated into whatever the RTOS needs, whether it's RTLinux or RTAI jmk: a empty .c file with just #include generates no warnings 01: HAL_LIB 02: HAL_tiro but I didn't specify -DMODULE hmmm let me try again actually it probably needs all the compiler switches and paths... an awful mess but perhaps the reason for the warning is that one or more of those aren't right for your system probably did you add tiro.c to the emc2 makefiles, so it is compiled with all those switches? yes in src/hal/drivers/Makefile try adding the little test file the same way or mv tiro.c backup same warning so... it's not your source, it's some include file yes well the thing looks fine the driver I mean still got to test it... that's a little more difficult bc I don't have a board on this machine lol and on the other machine there's no emc2 yet so... it's a tough one ;) it is -Wall with -DMODULE that generate the warning the kernel is built in order to not check module versions CONFIG_MODVERSIONS is not set that's probably it and it isn't set in order to not have problems with rtai paul_c: do you build BDIs that way? * paul_c tries t recreate the systems crash... crash? that's not good what crashed? Be carefull to disable "Set version information on all module symbols" under the "Loadable module support" kernel configuration paragraph, to avoid missing links when you'll use RTAI. from rtai 24.1.13 Readme.install in rtai 3.0 it's not specifiedanymore so I guess rtai 3.0 works with version info for modules *** Signoff: paul_c (Remote closed the connection) guess he recreated the crash I guess he succeeded in recreating the crash ;-( jmk: shall I send you the driver? alex_joni: sure... maybe you find some time to look over it would you like me to commit it to cvs, or just look it over well I think I should get an sourceforge account so I can commit myself but... I've been lazy ok... once you have your SF account, paul or ray or I can make you an emc developer Hmmmm..... Don't install and/or remove hal components when running you mean rmmod them? rmmod and/or insmod that should _not_ cause a crash it seems you can re-create the problem what exactly did you do, I'll try it here) while true ; do rmmod blocks ; insmod blocks.o ; done anthing in the kernel log? any clue how many iterations before it crashed? nope you had emc2 running at the time? or just a random collection of hal modules? emc2 running with dome test and by "crashed" you mean needed to reboot the box? just installed gtk-devel, and now I have halmeter & halscope I just love it when it works just another strange thing before I go when I start emc (scripts/emc.run) the font on TkEMC is not adjusted correctly (for the 3 axes) the letters are very small I have to go into Settings/Font and reset them I don't know anything about TkEMC (or Tcl for that matter) the TkEMC in emc2 is exactly the same as in emc1 well.. could be again something machine/install-related maybe some missing fonts or smthg anyways.. not that important I'm going to sleep now.. it's almost 2 am here ;) goodnight KDE Control Center - There is a screen with a little tick box to force KDE colours & fonts on non-KDE apps. * paul_c can't remember which menu it is under.... paul_c: running here just fine which of course proves nothing what OS were you using? Live? should I try too? maybe he crashed again... looks like it works ok here for around 2 mins 7200 iterations 10000 need more info from paul to try to reproduce or troubleshoot it well... no problem here there should have been something in the kernel logs... each iteration prints 5 lines here I'm really gone now.. I did a : so unless the crash happened on the first iteration and the log buffer never made it to disk.... goodnight alex ;-) while true ; do rmmod blocks ; insmod blocks.o ; echo "n" ; done and > file.out watch wc -l file.out gnight * paul_c looks at the code.... sigh ... theres a *lot* of people in the channel list I always seem to miss alex_joni ... dang. looks like paul crashed again (or went to sleep) so what's this 'stand alone interpreter'? do I need RT-Linux or the like to use it? what stand alone interp? what doc are you reading? or webpage, or whatever... RS274NGC_3.pdf someone spammed the URL earlier oh... haven't read that doc in a long time the interpreter is moduler, it calls "canonical machining functions" to do the real work says it's used to test NC code yes I think somebody built a set of canonical functions that simply print their names and return yes, maybe thats what I'm looking for so if you link the interp with those functions instead of the regular ones, you can just run g-code thru it and examine stdout I just read another doc on the canonical functions yes I havent fscked with EMC in a while... I got it installed and played around with it for a while I was telling my boss about possibly using EMC to drive a couple of lathes at work, one is already retrofitted with OpenCNC But I dont know the capabilities, seems like most of what I hear/read is stepper oriented, not servo motor oriented emc1 can do stepper or servo servo requires some kind of hardware (unless you are talking about step-servo, like Gecko 320 drives) supported hardware for emc1 is Servo-to-Go, Vigilant, Vital Systems, and Jon Elson's PPMC cards hrm I dont think so, these are old mid 70's Warner & Swasey lathes emc2 will eventually support all that and more, but not now I think OpenCNC is using a Vigilant card to drive one of the lathes the hardware I described would only send analog signals out to the existing amps and read the signals from existing encoders so it doesn't matter if the rest of the machine (including the drives) dates to the 70's yes, I'm sure that is the way OpenCNC is controlling the lathe... so the canonical functions actually use specific drivers to send commands via the mentioned ISA/PCI cards? much more complicated than that yes, I'm sure it is :) canonical commands send commands over NML (a comms protocol) to both IO and motion controllers IO runs in user space, motion in realtime/kernel space each of those in turn accesses the hardware devices the motion controller is very complex itself I'm just trying to get the 'big picture' of what it would take to integrate EMC into one of our lathes * paul_M fails to see what was killing the other box... hrm what is 14:00 GMT... like 10am EST? http://www.timeanddate.com/worldclock/ yup 10:00 so I missed the meeting by some time... hehe still going It don't stop till everyone is gone. I see actually I was just trying to get accustomed to IRC and found this channel the Debian package of ircII defaulted to this server So you using EMC ? no, I installed the Braindead CD on a PC in the garage some time back, but havent fooled with it much Im a machinist and C/Linux hobbiest, so... Thomas Kramer has some really interesting papers Do you do C++ ? I did for a while, I understand C++ fairly well, but I havent written anthing in a year or more with it wanna lend a hand documenting the source code ? well... are you using a specific documentation? I used doxygen for a while LyX and Doxygen hrm, I'd probably need someone to hold my hand for a bit... I'm no professional programmer by any stretch of the term so what are you needing, interface documentation? internals, api, general "wth??" - Usual sort of stuff gimme a few minutes to put up something up I did with doxygen... if I can find it... http://66.157.77.86/docs/ It's all C, and fairly primitive stuff, It was my first exposure to doxygen that's the sort of stuff... ok, so how would I 'get involved' ? got a SourceForge user name ? no, I've only poked around on Sourceforge, grabbed a few files here and there Did you install from a recent BDI-Live CD ? it's been probably 6 months I can get the CD I burned and check it out If you are running KDE, then you probably have all the tools that are needed... yes, I'm sure KDE was installed with it (becuase I lothe KDE) :) or is that loath, anyway the PC I installed it on is in the garage, collecting dust I need to plug it into my lan so I can SSH into it, or use VNC paul, it there some documentation I can read that describes how to get involved? the redbean cvs book is required reading... yes, I've delt with CVS 'very' little apart from that, you just jump in and get your hands dirty ok, so first thing, get an account with sourceforge, then get up to speed with CVS or maybe the reverse http://www.linuxcnc.org/EMC2-description.html has a couple of pdf docs linked to it... For the most part, the only three cvs commands needed are "checkout" "update" and "commit" the readme and coding style texts in the emc2 tree give some additional advice A SF usr name is essential if you ever want to make any commits I see hrm, so is the 'Code Notes' PDF where you need help? or, actual comments within the source modules? both ok, I'll see what I can accomplish in the comming week, as far as sourceforge and CVS I've got that URL booked hrm, this would probably be a really good way to become familiar with EMC (something I've been wanting to do) so how is the traffic in here? is it Sunday only? I'm around most of the time working to British Summer Time though... gee... Really should get you guys to work normal hours I'm on the east coast of the US lol my day job is from 8am to 4:30pm probably be running a horizontal manual mill next week for a while then back to the Warners (bleh) paul, is that CVS book you mentioned an o'reilly? I was just at Barnes & Nobel yesterday, think I saw on on CVS Coriolis google for redbean & cvs or follow one of the cvs-howto links from SF ik I found some flavor of ebook sourceforge probably has a more specific howto though Ok, I've got enough info to get started... getting started :) * paul_M finds an 'Excelent' G-code programming guide... http://www.schleicher-de.com/home/de_gb/download/manuals/gb/pdf_pronumeric/32238162.pdf looks Fanuc-ish Checking up on the syntax of G33 cycles I wrote a G33 cycle in C a couple weeks ago interpreting ? or doing the trajectory it's like a command line conversaiontal function http://66.157.77.86/c/g33.html I need to test it more, and it only uses a single type of infeed pattern (leading edge) *AND* it's for the OpenCNC control, which makes it useless to anyone else written as a canned cycle ? yes Not a true G33 then... well it spits out long hand NC code you have to paste into your program no, not at all G84 (or is it 86) is the usual canned cycle G84 as a tap cycle as a matter of fact that link I gave you is from the first release, I've since used regular expressions to error check the input need to change that on my page G84 - Canned Threading (on my lathe anyway...) what control? Canned cycles vary from control to control yes, G76 on fanuc/haas umm G71 on Okuma G70/G71 is the same as G20/G21 on my box yes, Okuma goes about things their own way like G15 H### for fixture offsets, instead of G92, G50 or G54-G59 'bout the only consistant ones are basics yes that's why I wanted a copy of the original RS-274D some specification written in stone er paper :) * paul_M wants a copy of the B.S. and I.S.O. standards... yes, I was going to order the ISO NC standard, but it was umm $56 US I think and it was only 14 pages... I forget the number ISO-6983 ok I have a Sourceforge account now usr name ? bytecolor bytecolour... added lol color, the yank spelling I gotta read about this 'true identity' stuff... post 11/9 paranoia lol, na just following instructions, being a sourceforge newb I'm gonna do some laundry, paul, thanks for the info, I'll check back in here next week sometime prolly tomorrow what time is it in gb? 1:50 (ish) ok, talk to you later