John I have a problem : your HAL_pin pid.0.enable sinks to much current :-) ;-) what is it doing? really if i connect it to axis.0.amp-enable-out then this pin never gets high but if not connected, then the pin does go hi? jep axis.0.amp-enable-out gets high if it is not connected when i turn on EMC ???? linkps axis.0.amp-enable-out pid_enable linkps pid.0.enable pid_enable just checked the code in pid.c, don't see anything that should be modifying it let me do some testing hm pid_enable is a bit also when i want to set the signal pid_enable manualy high with halcmd that doesen't work inivar -ini configs/emc.ini -sec HAL -var REALTIME_MODULE -num 3 "halcmd sets pid_enable true" only works if pid_enable has no writers jep i have disconnected axis.0.amp-enable-out before it's possible that the motion module is constantly setting axis.0.amp-enable-out false? can you send me your .hal and .ini files? that will save me some time no if i turn on emc without connecting sonething to axis.0.amp-enable-out it gets high hmmmm one Moment how are you observing the signal? halmeter? no with halcmd show i will test it again ok are you getting following errors? amp enable is turned off when an error happens... so it might only come on for a few milliseconds if you get an error right away hmmmmm i have tested it again now it gets high ????????????????????? looking at your hal file is there a function like evoreg.1.read? to read the encoder? jep that is my driver to write and read everything a beter name will be update I only see an addf for evoreg.1.write, nothing for read or does the "write" function both write DACs and read the encoder inputs? I was expecting something like: jep i have to name it "update" addf evoreg.1.update servo-thread 1 jep note: 1 means run it at the beginning of the thread, before the motion code, so that the motion code can use the encoder data paul_c lathe_fork emc2/src/libnml/inifile/ (inifile.cc inifile.hh inivar.cc): inivar now accepts a -num param and returns the Nth match. The changes in this directory break usrmotintf, but that can be fixed. The rest is up to John. paul_c: should I check out the lathe fork? Or can you add this change to the main branch? jmkasunich: Checkout the fork I was afraid you were gonna say that * jmkasunich looks for his cvs book co -r lathe_fork cvs -d:ext:jmk@cvs.sourceforge.net:/cvsroot/emc co -r lathe_fork emc2 good group this morning but awful quiet paul_c: did you run a "make clean; make" after the inifile changes? Of course.. didn't work here while compiling interp_arc.cc make headers and then cd to libnml/inifile done there is no inifile.h but a chain of includes that starts with emc.hh wants one * paul_c is working on that.... morning dan, good to see someone else from the northwest dave-e: good morning I've been going back and forth between my computer and the shop good exercise dave-e: where are you located? Selah, WA, 5 mi N of Yakima I'm in Beaverton, OR a mere 200 mi away Cool! My machines are sloooowly getting unpacked I keep saying that someday I'll have the Mazak running Do you have a web site? not for the shop should do that I'd like to see some pics of the Mazak plain old V5 I will look it up on ebay that's where I get a lot of info these days right now I'm fussing with getting a 30/80 phase converter installed try http://www.bomek.se/maskinpark.htm and page down...it looks short ...but is really 8' high Ok, I see it. *** alex_joni (~alex_joni@80.97.178.14) has joined channel #emc hello guys hi alex what's up? jmkasunich: how can i change the max following error ? the parameters are read only and setting something from the gui will be ignored edit the ini file following error is set from the ini file with emc stopped it can be the case that you won't be able to write the file (need to be root) MIN_FERROR is the allowable error at zero speed FERROR is the allowable error at max speed ok jmk: I have seen some changes from paul regarding inivar yes, we're trying to make the HAL configs a little less ugly paul_c lathe_fork emc2/src/ (20 files in 10 dirs) Fixed the references to INIFILE - Need to work on some of the other cmpile time warnings.. (later) aha I see... getting rid of the RTMODn and RTMOTCFGn mess in the ini file should also solve the problem that happens when a module needs more than one argument how about multiple params to RTMODCFG ? exactly what I was gonna ask ;) ;-) I thought it should be related how will it be done? REALTIME_MODULE=encoder num_chan=2 period=1000000 for example there can be multiple REALTIME_MODULE lines aha that's why inivar -num Paul's mods let the run script extract them one at a time yep I'm working on the run script mods now nice the parameter MIN_FERROR in the ini file changes the hal_parameter axis.0.f-error-lim but FERROR doesnet change hal_parameter axis.0.f-error the param f-error-lim is the limit (which is speed dependent) the param f-error is the actual error, not a limit so axis.0.f-error results after moving the joint you can use halscope to look at both of them, if fabs(f-error) > f-error-lim, you will get a following error right it should normally be at or near zero with steppermod? emc2 - doesn't use steppermod sorry stepgen ok what I meant was ... not freqgen the error will usually not be zero, because stepgen, freqgen, and even servos have discrete counts for feedback but it should be less than one count I see (less than one count when stopped - when moving there will be more error) the problem is that when i turn on my amp emc goes immediatly to estop. following error? jep with feedback? jep use halscope what kind of feedback? trigger on amp enable turning on capture axis.0.motor-pos-cmd and axis.0.motor-pos-fb see what is happening when the amp turns on i have a driver for a board with dac out and encoder counters ok what's your ferror, and your scales? ferror is 100 scale is 1:1 the encoder has 500 lines ? ? there is no scale at the moment just looking at evoreg.c (didn't realize you sent that too) enc_in[n] is a float but you are using readw() to read an integer count from the encoder hardware and stuffing it into enc_in[n] that won't work you need to read encoder counts into an int then multiply by a scaling parameter and write that to a float take a look at alex's hal_tiro.c driver I have to go, my wife just got home I'll be back in 4-6 hours kay ok but emc is counting in the gui when i turn the shaft maybe I can help Imperator_: fill me in i have to read your driver it's pretty much very basic did you commit yours on cvs? not yet it is very basic at the moment i thought for exampe the scaling is not neccesary for the first tests depends on how you skip it where do you do your counting / updating? how do you mean that ? you should have a procedure that runs realtime that reads the hardware and returns the counts/postition jep for me it was static void capture(void *arg, long period) *(cntr->count) = LS7166Read(n); no cfg yet for your driver? another question... you have PID not configured for axis0 that could be a problem you mean the P I and D parameters in the ini ? yes P actually if i set it it will be changed back after shuting down emc2 that should not be did you set it by writing into the ini file? or did you set it from tkEmc? jep befor starting emc strange seting something from tkemc wil be ignored there cames a message I need to restart my internet connection be back in 5 mins. I was missing some files ... emc2 wasn't running just co-ed it I tried changing P from tkEMC got: ignoring issue of unknown command 103:EMC_AXIS_SET_GAINS I see that PID-related stuff is commented out in emctaskmain.cc maybe because there is a HAL component PID now and the values need to be set to the params of pid !? still there martin? paul_c lathe_fork emc2/src/emc/ (7 files in 2 dirs) Convert inifile checks to bool types. jep i am back from eating I have seen that you use a pid-component yes i think i am one of the first one in order to use it you should pass params to it... right? I think that too but the PID values are not read from emc.run I think that needs to be done... what are you doing with your encoder card at the moment ? well... nuthing much turning motors do you have a dac card ? I am still planning on building a cutting table no dac it's a simple encoder readout board try putting some values to pid soldered by your own ? yes and designed solder a dac to the card also :-) need such a board? i have that siemens cards LOG GAP ha ha Imperator is happy !!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!! maybe I have the first servo running with EMC2 !!!!!!!!!!!!!!! Congratulations to you, John, and Paul!! :-) jep and my driver is working also it's cool amazing that a adult person can be so happy about a turning motor :-D Tell us about your machine Imperator... hey Paul are you here hm that is the problem, there is no maschine, it is only a galil servo amp and a servo under my desk Ok...working on a machine here with Renco encoders and also Gallil amps... but i hop that i have a maschine end of the year with EMC2 ?? With EMC at the moment... which card ??? Would EMC2 be better? Using Vital Systems card... I think so Paul, John and all the others are working hard to make it much better For the log, thanks to John and Paul I read some of the HAL document...reminds me of LabView... yes but up to now without gui Well...it took NI years to do that right... I m somewhat ignorant on basic linux stuff here....For example how would one compile the strip chart ? EMC2 ?? Well, in emc, but the real question is how does one use a Makefile to compile ? just type make but i am not shure if i have understood you correctly Ok...i knew it was simple, just not specifically what it was... I tried typing makefile... the normal build proces is ./configure and then make Thinking it was a script... with emc1 it is not so easy What does ./configure do ? For the emcstripchart, that s just an independant module...so it should be easy as that, I guess... I am not a specialist, but it collects information about your Linux installation. For example it checks if there are all required librarys and so on and where they are Which motion board are you using on your test bench setup? SteveStallings: Got the G33 notes I have a SIEMENS card from ebay with 16bit DAC, encoder inputs, and digital io for three servos Paul EMC2 is runnig with a servo ! "and diigital" ? some digital input and outputs for enabling the amps, and whatever Oh..I/O... The next stage is to break it all... Hi Paul...The runaway problem I am having is bidirectional, not only in the down direction...Still need to get a new download in, however... wb9mjn = Don ? Yep... Have you reduced the PID gains ? But, today i did find a loose wire on the DAC to Amp connection today... That won't help matters Nope....but i m doing some wiring, and wont be able to test what effect that has till later... There were two wires into the t.b. ground, and one was inserted al the way, and the other was not....The one that was not was the z axis signal minus..... I can send you a PDF that Dave Engvall did on tuning servos if that would help Ok... What I did , just intuitively was set a low gain.....then increase the I to cut down on vibratory action...Then increased D for axis quickness...but when the D was increased, everything got real stable....... Which is where it sits now.... Have you read up on the Ziegler-Nichols methods ? Nope.... Basically, you set I, D, & FF gains to zero Think the runaway is not associated with the PID tune...but Hey, I m a newbie at this... Yep, that is what I did... Increase the P gain until the systems goes in to sustained oscillation measure the frequency Well, in my case I had to decrease the P until the vibration was bareable! Ok... and then apply some "rule of thumb" calculations to derive the final P, I, & D values Ok that sounds straight forward...The vibration frequency i heard (felt) was about 30 hz... http://www.jashaw.com/pid/tutorial/ and http://www.shu.ac.uk/schools/eng/teaching/rw/pidtutorial.htm The second is probably the better one. Dave's paper on it's way Thanks... Probably should go through my Kuo notes, and do a root loci.... Eventually...hi... Got any photos of the machine ? Not yet.... Its a D+M 6...which is an old vocational school machine... Its a bench top category machine...I pitched the table, steppers and stepper drive.... Built an electrical panel into the case...put on a OPTO 22 board, relocated the original spindle drive, put in Gallil amps... That was after hand grinding the Z ways into a reasonable shape...dovetail ways, with 5/8 ball screw..I also put in a new ball nut, which is a double nut... Re did the Z axis motor plate to adapt to a servo motor, reusing the original 2:1 timing belt drive...and adding a brake... Replaced the ball nut bearings with a little more robust situation... Put in limit switches...and that was a good thing! Limit switches always are... The limit switches are setup to go parallel to the amps, and series to the OPTO 22 Input module... Are you up in Michigan by any chance ? Nope...I am near Chicago... it would be wb8mjn, in Michigan,,,hi.... Welp, need to get back to the wiring...will leave this up, and be back and forth to this room... John, welcome back..... you now have a real servo user!!! :-) * paul_c prods SteveStallings .... and he seems to have regained his composure! 8-) Hi John, scaling the counter values was the key Yes Paul? I & K in G33... Imagine fo a moment that a G33 with just I will cut a scroll I was reading back... congratulations Martin! and just K will cut a plain old thread in Z... I forget which is which, but I or K alone will cut a thread, the other a scroll. I in X, K in Z I,J,K = X,Y,Z HAL is great john thanks Paul, when the time comes these old manuals have lots of stuff about tool orientation, compensation and the like... Will need to start thinking about tool offsets soon... Interesting also, they tend to treat threading the same as feed per revolution when discussing feed rates AND they assume that the programmer provides excess travel for approach and retract, i.e. the G33 move is expected to have following error at the start and end. jmkasunich: The lathe fork compiles cleanly now. * jmkasunich does a cvs up One thing to note with the -num param Using -num 0 is the same as -num 1 and the same as no -num at all, right? -num is optional. right: no -num and you get the first instance -num 0 and -num 1 also give you the first instance, -num 2 gives you the second, and so on yup I'm starting the loop at 1, so it works fine and -num 7 (when there is only 6) will return nothing and flag an error on std-err flag an error on stderr? I didn't see that or do you mean it just returns non-zero? * paul_c double checks... sorry, returns an error on stderr if the file is not found hmmmm, that might result in an infinite loop (the error message could be interpreted as a result... ) Not on stderr ok * jmkasunich doesn't know the finer points of VAR=`command` I wonder if it should call exit(1) if inistring is NULL? paul_c lathe_fork emc2/src/libnml/inifile/inivar.cc Add an error message to inivar. paul_c: still a few "warning: comparison is always false due to limited range of data type" errors simIoControl.cc:124 emcsvr.cc:35 emctaskmain.cc:2401 emcsh.cc:1766 and 5355 iosh.cc:221 and 1459 nothing that stops it from compiling though paul_c lathe_fork emc2/src/emc/ (iotask/simIoControl.cc task/emcsvr.cc task/emctaskmain.cc) Caught a couple more cmpile time errors. paul_c lathe_fork emc2/src/emc/usr_intf/ (emcsh.cc iosh.cc) Caught a couple more cmpile time errors. : Next ? * jmkasunich is fighting with bash quoting stuff make is clean now if the args portion of the line is cfg="0 0 0" what gets passed to insmod is 'cfg=0"' 0 '0"' All I did was to provide you with the method I know ;-) inivar is working perfectly I'm just fighting with the scripting - I'll get there eventually Ah... a kbd<=>seat problem bash quoting rules can be... subtle... when dealing with quotes inside quotes and command substitution programming question: I have a array of bit's hal_bit_t *digital_in[48]; and i want to write a integer in one step to the first 16 bit something like this (int *)port->digital_in = readw(*port->io_base + 0x20); but it gives a warning how knows the trick you want to read a 16 bit port and write to 16 individual hal_bit_t variables, right? jep and then the next 16 bits something like this: int temp; int n; tmp = readw(*port->iobase+0x20); for ( n = 0 ; n < 16 ; n++ ) *digital_in[n] = tmp & 1; tmp >>= 1; } one moment i want to transfer the 16 bits that i have read to the array of bits that's what the loop I just wrote does hm, but i think there is a trick to do it in one step nope... hal_bit_t is a char the data you read from the port is packed 16 bits into a single short hm you need to unpack it the source is a 2 bytes long, the destination is 16 bytes long ok unpacked data wastes a little memory, but allows individual hal_bits to be modified without read-modify-write operations that are not thread safe ok and bit fields are also no solution ?? hal don't knows them, i think nope hal bits must be unpacked ok, I do that physical I/O is usually packed servo is running ok the prozessor is fast Imperator_: any luck with that problem? was it the pid? t = 1; for (n=0 ; n < 16 ; n++) { *digital_in[n] = (tmp & t) ? 1:0 ; t << 1; } that's another way to do it (shifting a mask instead of shifting the data) *digital_in[n] = (hal_bit_t) (tmp & t) ? 1:0 ; (just in case it needs a cast) right but the ? ; involves conditional branches - I avoid them for speed reasons... realistically, both versions are pretty darn fast on modern cpus Modern compilers will optimise a ? faster than an if/else loop agreed... but I was avoiding all branching digital_in[n] = (hal_bit_t) (tmp & 1); tmp >>= 1; don't move the mask, move the data * jmkasunich is nitpicking both will actually be limited by memory bandwidth wanna try doing it all on one line ? do it in one line - > how to make a program unreadable no... probably doable, but readibility suffers and gcc is likely to generate the same code for the two line version' To nitpick even further - Both will be limited by cache speed. Main memory access tends to be done in bursts :-) * paul_c was thinking more about reducing the whole for loop down to one line... the first version from John is the one I understand hmmmm the mask version... if the mask is a short, and you are shifting it <<, then the loop terminating condition can be mask==0 and of course instead of *digital_in[n] you can use a pointer and just inc it hal_bit_t **ptr; ptr = &(digital_in[0]) in the loop: **ptr++ = ( (tmp & mask) ? 1 ; 0 ); for (t=1; t!=0;t<<1) *digital_in[n++]=(tmp&t) ? 1:0; still have the conditional branch though yes you can tell we've all done embedded or assembly programming.. sitting here trying to optimize a loop that takes about 0.1uS on a modern box for (t=0;t<16;t++; tmp>>1) *digital_in[t]=(hal_bit_t) (tmp&1); or was it a , at the for? I dunno, I've never done that trick with the for anyways... not important right... but fun ;-) what was the problem with Imperator_'s setup? was it the pid? no scaling on the encoder feedback aha Now let's see you do it in assembler what CPU? good idea ;-) in one line :D 4004 lol LOL F8 then.. I'm rusty at one time I could do it in 8051, Z80, and X86 I was wondering... about the pid the hal one that totally ignores the P,I,D,FF, etc in the ini file.... ;-) there should be some part in the startup script, that reads the settings from emc.ini and sets them as params to pid.. right? yeah... HAL configs are a sticking point... Paul and I nearly came to blows over it last week ;-) but we're trying to improve things Which is a polite way of putting it.. or should it get moved to *.hal ? my personal inclination is to stick it in *.hal, but that has it's own problems really? like? then the config is splited over some files the reason I don't like PID for example in emc.ini is that some systems (stepper) might not even need PID, but instead need things like step_setup and step_hold so we wind up with a ton of parameters in the ini file, and no one system ever uses them all you must have *.hal if you put the pid params in the servo related .hal file, and the stepper params in the stepper related hal file, that's nicer BUT... you wind up with machine specific numbers in a bunch of places pid_tuning.hal yes how about a include directive in *.hal? Hi all...gotta question on EMC PID values.... include pid.hal include servo_pid.hal I and D are gains in EMC, but times in references....? and it also turns into a nightmare trying to give a newbie support over irc or email.. gains right - if everything is in one file, you can ask the newbie to mail it to you if there are a pile of includes.... things are tougher I don't think it would be nice to have anything in one file... How does one get a gain, from the Ziegler Times ? so there are arguments both ways always will be The configs should be simple... or... you should be able to choose from different configs If you have to jump through endless hoops to configure a system, HAL has failed (IMO) the existing method has the disadvantage of dozens of unneeded parameters in the ini file (unneeded for a particular system), but the advantage that everybody's ini file looks about the same, only some values change maybe hal_gui could eas things up a bit for newbies nope it is hard to make complicated things easy to use it has the disadvantage that you may start changing params that don't do anything on your system... wb9mjn: You have determined your time constant ? and try to tune a thing that isn't actually there true newbies won't understand HAL or care about it... they will start with a pre-written ini file (and .hal files if needed) what system could a newbie have? Yes, and a critical gain, too.. .050 seconds and 600 ... steppers, stepgen, no feedback... for example, parport steppers.... a standard set of ini/hal files can set that up Gave up on emcstrip chart, and just hooked a scope to the control voltage...hi... P=360 I=0.025 D=0.00625 FF gains all @ zero. Ok...So, the documentation is wrong... It says gains, not times for the I and D .... how did you figure that one out? paul_c? Those are the numbers I calculated too... John i think hal is easyser to configure when it exports only the axes specified in the ini http://www.shu.ac.uk/schools/eng/teaching/rw/pidtutorial.htm Yep...I read that.... 'bout half way down In there it says the I and D are times...not gains...but in the EMC manual it says they are gains... Imperator_: you mean no axis.4.whatever if there isn't a 4th axis? jep So, I was confused.... I agree 100% me too my terminal buffer is set now to 5000 :-) * paul_c is no expert on PID loops, but the figures are usualy referred to as "Gains" BTW, the wire fix helped allot...but it still went out of control on the first start up...but not after...most likely due to counter zero limit being exceeded... the problem (at least for now) is that the things are exported at insmod time... while the number of axes isn't made available to the module until later if num_axis was a command line parameter to the motion module then it would be no problem wb9mjn: Have you done an update from the current CVS surces ? the ini is parsed later ? Not yet....going to go try those values and see what happens...back in a bit... before you go... Imperator_: the ini is parsed many times ;-) A small change was made to the Vital driver that may help... the run script parses it and passes some parameters when it insmods the motion module (and the hal modules) then later the user space code parses it again and sends commands to the motion controller to do most of the rest of the config $INSMOD $EMC2_DIR/rtlib/$EMCMOT base_period_nsec=$BASE_PERIOD_NSEC \ servo_period_nsec=$SERVO_PERIOD_NSEC \ traj_period_nsec=$TRAJ_PERIOD_NSEC \ key=$SHMEM_KEY How much easier it would be if all the configs could be deferred paul_c: you mean if you did not have to export pins, etc at insmod time? yup agreed.... that's why I didn't simply propose adding a MODULE_PARM called num_axis... that's the easy solution to the issue imperator raised, but not the right one would that not bring problems up? like trying to set up links with pins that don't exist yet? configs would have to be done in the proper order install modules tell modules to export pins, etc create signals connect pins together with signals right now, the first two steps are done at the same time lemme throw in a problem... An 8255 based card which is why modules need insmod time parameters like cfg="0 0 0" or numchan=3 or base_addr=0x378 you would have to pass some messages before telling the modules to export pins If the card is insmodded with a default setting (say all 24 pins are inputs) and at config time, you needed to change it to 12 in & 12 out.. right.... with HAL as it is now, you must know the IO mix at insmod time "config time" is kind of nebulous.... after all, you must know _which_ modules you intend to use at insmod time - that is part of config how about un unregister function? register 24 pins then decide to unregister 12 and re-register as inputs the basic problem is that registering and unregistering are not realtime safe... they can be done safely at insmod/rmmod time, but not at runtime (unless/until I refactor the core of hal_lib - something I intend to do eventually) well... I think all the solutions above need some kind of rewriting of the code currently hal config is divided into two classes - stuff you can only change at insmod time, which is basically the list of pins, signals, functions, etc and stuff that you can change at any time - linking between pins and signals, and between functions and threads and also parameter values can be changed anytime) maybe define some rules... no removal of pins allowed when they are linked etc. I made a mistake... the first list is pins, params, and functs alex_joni: the problem isn't concern about whether they are linked or not there is internal data (metadata) about each hal item (pins, sigs, etc) like name, type, what is linked to it, where in shmem it is stored, etc that data must be protected from corruption due to simultaneous access by multiple threads I see currently it is protected by mutexes, even if you are running halcmd's in two shell windows at the same time, linking and unlinking, nothing will get busted but since a mutex is involved, calls to export, link, etc, can block if another process is also accesing the internal data blocking in realtime is bad, so those calls can only be made from insmod/rmmod (which is not realtime) how about rmmod then? remove the component, and reinsert it with the right confs although.. there should be somebody able to do this that can be done, but is really ugly... I know not a good one :( face it, if you have to remove it and re-install after you know the right configs, why install it with the wrong ones in the first place... just wait until you know the right config yes so... insmod * paul_c thinks john has missed something.... * jmkasunich listens but not export of pins, params, functs wait for a configuration_message then export stuff and start RT insmod does not have to be purely responsible for starting or stopping a single task I really meant loading of the component wheather it's insmod or smthg else insmod could set up a number of kernel threads, some RT, some not... how? jmkasunich: When you are ready to rework the HAL stuff, I'll draw up some diagrams and sample code. I'm ready to talk about it any time draw up your thoughts and send them over * paul_c needs a little time to do the sample code. this is the kind of stuff I prefer to think thru for days/weeks before serious coding starts understood emcmot is kind of unique, in that it has a user space helper that reads the ini file and sends it messages.... And there are ways of limiting access to kernel resources by a single usr space app. NO other hal module has the benefit of that... another reason that things like num_chan are delivered as insmod parameters so all other have num_chan? or most anyways? num_chan, or cfg, or whatever is appropriate yes information that is needed to decide what should be exported well...maybe then it's easyier to change only emcmot /* export axis pins and parameters */ for (n = 0; n < EMCMOT_MAX_AXIS; n++) { in the case of the 8255 board that paul mentioned, with today's HAL you would have to tell it how many inputs and outputs at insmod time change to n yes.. and? right - but num_chan must be known at insmod time yes today, num_chan is set by a EMCMOT_SET_NUM_AXIS command thru emcmot shared memory, long after the module is loaded inivar -ini $INIFILE -var AXES -sec TRAJ let me try that in fact, the existance of the SET_NUM_AXIS command implies that the number of axis can be changed at any time.... 'ang on a mo... how about changed to get lower than exported at startup? What do you think SET_NUM_AXIS does ? is it possible to let the modules to insmod by the system ? The reason for this question is that at the moment a EMC user has to be root, and this is in my thinking a big problem. why? Imperator_: why is that a big problem? Imperator_: that's a separate issue, I'd like to stick to the configs since this is a productive discussion it is a safety problem the answer in a word is "sudo" yes ok and: cutting machine, not internet server SET_NUM_AXIS changes the global num_axis and emcmotConfig->numAxes SET_NUM_AXIS changes the number of axis that emcmot responds to - There are still eight (hard coded) available. it's true that the user space parts of emc never issue a SET_NUM_AXIS command except at startup, but from the motion controller's point of view it could be issued anytime correct - eight... and right now the motion controller exports eight sets of hal pins, even if you only need 3 that's what imperator was objecting to - it clutters things up he (and I) would prefer that if the ini file says AXES = 3, that only three sets of HAL axis pins are exported OK, so three options.... Welp....Those values were very oscillatory...Had to bring D way up to get stability, then brought P and I up to get settling accuracy, and D along with the P... 1) insmod with a num_axis param - Ugly and restrictive Was able to set the accelleration up to 2, and now it does the 1 inch jumps in about 1/2 a second.... little problem here 73 all for now...Thanks for the help.... agreed - but easy and quick to impment bye wb it seems that iniaxis initializes all 6 axes 2) Be damned and export a full eight axis - Wastefull on resources. emxAxisSetMinPositionLimit 3) Defer exporting of pins until actual configuration - Needs a new approach. right... we have 2 now, could do 1 easily, but don't particularly like it, and 3 is hard (but a worthy long term goal) tried 1) needs adjustments in other modules.. I think wb9mjn: If you read up on PID tuning, there are other "rule of thumb" calcs you can use... Some ideas for Option 3 would allow the shared memory to disappear and hopefully make things a little more robust. part of the shmem anyway (the metadata part) I just crashed my machine :( with emc2 ? what happened I did a manual insmod for motmod and it crashed? probably bad timings oops paul yelled at me for the lack of defaults on thread timings I thought I fixed it several weeks ago they default to 0 right, my fix was to make the insmod fail if the periods are zero I did a: insmod motmod.o base_period_nsec=5000 servo_period_nsec=100000 traj_period_nsec=1000000 num_chan=3 5uS is pretty darned fast paul wanted me to put in non-zero "acceptable" defaults instead, and I was stubborn guess I didn't transform it correctly ;) 50000ns = 50uS, that's probably what you wanted yes I dunno if that can be checked or not... values that would crash one PC might be perfectly good on another it works now and motmod exports only num_chan axes the problem is: I get some error messages: bad return value from emcTrajSetAxes in iniaxis.cc the question is... should we continue what alex has started and get insmod time setting of axis working (option 1) to make things nicer while until option 3 happens? or just leave it alone? * paul_c would be inclined to use 2) for the time being. I think if there is no easy solution use option 2 I would go for 2) for now and maybe 3) later good enough some major refactoring of the HAL internals is already planned... 3 can be part of that do you have some details ? not too many :-) Option 1 introduces too many problems... strange thing it's a COMM problem COMM_ERROR_TIMEOUT one goal is to move the metadata out of the main hal shared memory area into kernel memory maybe with 3) remove it completely remove what completely? the use of the metadata * paul_c hides metadata is things like the names of HAL variables without it, HAL doesn't exist for instance, the list of pins and signals you see when you use halmeter- that list comes from the HAL metadata seems I misunderstood you Some ideas for Option 3 would allow the shared memory to disappear part of the shmem anyway (the metadata part) right the actual hal data (the value of a pin or parameter) needs to be in shmem, cause that's how the data moves from one module to another Some ideas for Option 3 would allow the shared memory to disappear into kernel space where it can be protected from errant lusrs but things like the names could be moved into kernel what paul said ;-) I see ok today halcmd directly manipulates the metadata to link things, or list them the errant lusr after the refactor, it would use system calls, and the manipulation of the data would be done in kernel space by the code that implements the calls and also provide some valuable safeguards so far my biggest problem with the refactor is building lists (as in halmeter, halscope, and halcmd show xxx ) today that code just grabs the mutex, goes in, and runs down the metadata lists if that data was made private, calls to find a single item would be easy, but a system call to run down the entire list would have to return the entire list how is the list stored? could you point me to the file? a "get first" / "get next" model is vulnerable to changes to the list linked lists hal.h is the public api hal_priv.h contains the metadata structures and some private functions hal_lib.c does all the manipulaton of the metadata I like this: Complexity here is a small price to pay for simplicity later. :) however there is code in halcmd, halmeter, and scope_vert that runs down the lists (those files include hal_priv.h - a system call based implementation would not let them do that) what it comes down to is that hal_priv.h needs to be truly private * paul_c dislikes the notion of "private headers" I wonder why it's named hal_priv... :D private headers that tom, dick, and harry can #include if they want aren't really private but it's better than having the metadata structs in hal.h.... then everybody would have access to them The code is GPL, so anyone can see what is inside foo_priv.h we're not talking about that kind of privacy... we're talking about the kind that comes from static variables (file scope instead of global)... like private class members, etc I was using "everybody" poorly not people source code some (most) modules have no need to know the stuff that is in hal_priv.h but all hal modules need to know the stuff that is in hal.h suggestion: Have a look at how the asm/ or bits/ headers are restricted If/when the metadata moves out of shared memory, it won't matter if the usr tries to manipulate the data directly 'cos he/she won't have direct access to it. emc2 running again... I undid everything ;) alex_joni: if that is your working copy, CVS is likely to still think that is has been changed, unless the undo is _exactly_ the same as the original I actually did a co ok... that's what I was about to suggest ;-) removed my files, and co them again was easier cvs diff -u * jmkasunich goes away in about 30 mins you are just trying to cheer me up now ;) yep so ... should I .. try and get this 2 axis bed going with its existing controller ... or get a servo card? for emc this is the old laser? yeah what motors? small servos 3kw AC things ... More important, what amps & encoders round encoders ... not resolvers no, deffo encoders how do you talk to them? politely part No. ? :D analog ? voltage? or bus? well, theres a +-10v signal I think going into them aha What make & model amps ? wait one, I try to rememebr Too late. well... it deffinately is for me... too late that is gotta go.. gotta work today servomac ... http://www.servomac.co.uk/products.htm goodnight alex but AC servos, not DC gnight all night they are 3 phase in, +-10v in and encoder out ... I suppose I need to find out how many pulses per rev and all that stuff Got a model nuber for the amp ? the extant controller is a "Sapphire" by peninine automation, circa 1997 mmm, off hand, no you have any servomac data? I did search the web for the model number a while ago, found nowt Damned java... Why the hell do people want to use it on web pages... * paul_c rephrases that... well .. for some things, there is no alternative why the hell do people want to use java. but genrally, yes its bad on web pages same reason people want to use C ... java hardly ever works on my boxes - So it isn't portable. and, you can certainly write code that is valid C and java ... trivial code, admitedly probabl ;) whatever, lets not start another round of the language wars so ... swervo cards for EMC ... 'mericun V english ? so, servo2go considered ancient ... what is there PCI that is supported? ISTR you naming one a while ago * robin_sz discovers the offending Java using Java for navigation considered a deep form of fuckwittery http://www.servomac.co.uk/images/uac.jpg # yep, thats them ... 3phase in, movement out methinks that those amps were originally made by NUM part of the Schnieder group * robin_sz nods Gut feeling - A serial interface, and *possibly* an anologue velocity control serial interface? The serial interface would report possition and be used for config parameters hmmm Is there an RS232 lead in there ? dont think so encoder comes straight back to the controller reolver goes to the drive OK... and a phono plug goes from controller to drive eeuw quite Two tasks for the next week actually it might have been a 2.5mm jack, but still euwww Identify the encoder make & model Contact servomac UK and bully as much info out of them as you can heh :) Failing that, talk to Pennine dunnoi if they still exist I think they got bought up by some CNC spares outfit 01422 370109 Pennine IS the CNC spares outfit the controller is sort of 6502 and lots of TTL technology oh , ok www.cncspares.co.uk the controller is a pennine home-built one, ie looks like very low run PCBs etc the same phone nuber too... has functions to dump the operating code to an eprom programmer etc the secret code to access the set-up screens is 0422 ... figures STD code sexually transmitted disease? standard dialing code the max speed it runs at is around 4m/minute in G0 as slow as that ? the ballscrews are 5mm or 10mm pitch * paul_c would expect at least 10m/min I reckon the servos should be capable of 3000 rpm so like you say, at least 10, 15 m/min I reckjon thats just a limitation of the crap old controller Another little jobbie - Bung a scope on the data lead scope ... * robin_sz adds 'buy scope' to his todo list see if it is digital data or analogue * robin_sz suspects anaglogue and use one with floating inputs... the servo card on the controller has 6 encoder inputs and 6 'control out' phonos ... I suspect its generic +-10 only 2 axes used, of course * paul_c has a selection of servo cards.... I remember If it is an analogue interface and quadrature encoders, you may be in with a chance. well, lets hope so