Back
[00:00:09] <andypugh> salvarane: You may need to "touch-off" your system so that the working coordinate system matches your workpiece the axis limits
[00:00:12] <salvarane> motor 3 Amps , 4 leads | step angle 1.8 | phase resistance 0.9 | phase inductance = 2.5 | holding torque (Oz-in) = 175
[00:01:17] <andypugh> When you send G0 X10 what does the emc2 screen say the X position is?
[00:02:33] <andypugh> If you go to X20 is that 25 or 3o in actual real-world space? ie is the scale wrong, or is there a 5mm offset?
[00:04:56] <theorb> theorb is now known as theorbtwo
[00:06:19] <salvarane> when I run G0 X10 into grafica window emc2 , the axis X it is moved from 0 to 254
[00:07:08] <salvarane> G0 X20 is that ~25 !
[00:07:54] <salvarane> in the real-world space
[00:08:50] <salvarane> In the gcode I not inserting 5mm offset
[00:11:34] <SWPadnos> that's the ratio of inches to mm
[00:11:54] <SWPadnos> G21 X10 should move to 10 mm, G20X10 should move to 254mm (10 inches)
[00:15:16] <salvarane> the ratio is mm
[00:16:47] <salvarane> G21 X10 and G20X10 moved to 254mm
[00:17:52] <SWPadnos> that makes no sense
[00:17:53] <salvarane> sorry G21 X10 moved 10mm into grafical window emc2
[00:18:06] <SWPadnos> ok, that makes more sense
[00:21:39] <salvarane> when I load the gcode into emc2 the graphica window it makes to see me the metric system , but the execution execed of some millimeter
[00:22:23] <salvarane> on piece of iron
[00:25:16] <andypugh> If it is a fixed offset it might just not be touched-off. You can set you coordinate system zero anywher you want.
[00:26:18] <salvarane> yes I fixed the home XYZ and set O machine , Ha have moreover set into steper_mm file conf "SCALE = -200 ", it is the pssible problem
[00:26:48] <salvarane> for the X and Z axis
[00:27:01] <andypugh> -200 might be correct, that is one way to make the axes move in the correct directions
[00:28:23] <andypugh> Fixing home XYZ is not the same as setting the G54 origin to the correct place on your workpiece. The G-code probably assumes that X0 Y0 Z0 is the top left front corner of the material.
[00:28:31] <SWPadnos> salvarane, can you post your ini file on
http://pastebin.ca ?
[00:28:55] <salvarane> yes, wait please
[00:29:03] <andypugh> But, anyway, it is far too late here for me to be any help. Goodnight all.
[00:29:09] <SWPadnos> see you
[00:30:44] <salvarane> http://pastebin.ca/1952275
[00:31:02] <Valen> salvarane: can you go a G1 X10 then a G1 X20 and see how far it moves in the real world in between those two points?
[00:34:48] <salvarane> sorry but I not connect the machine in this moment but when I proved this options the movment exceed of the 5 mm
[00:36:11] <salvarane> for the X = 140 the X to result is 155 mm and the Y = 65 to result 72 mm
[00:37:38] <salvarane> in this moment the G1 X10 and G1 X20 to move the axis X 10mm and 20mm to positive moviment
[00:37:54] <salvarane> on grafical indow emc2
[00:39:14] <SWPadnos> of course. if you program a move to some point, the display had better match that value when the machine stops moving
[00:39:37] <SWPadnos> there is no scale problem internally (unless you're programming in mm and viewing inches, or the other way around)
[00:40:18] <SWPadnos> when the on-screen motion doesn't match the actual machine movement, the problem is that either the scale is set wrong, or the machine is losing steps, or both
[00:44:27] <salvarane> in order to resolve the problem I must increase the "SCALE = -200"
[00:44:45] <SWPadnos> it sounds like you need to decrease it
[00:44:59] <salvarane> the controller SCALE= -100
[00:45:24] <salvarane> is possible, a function for calculate this value
[00:45:31] <SWPadnos> figure out what the scale should be from your motors, drive settings, gear ratio, and screw pitch ...
[00:46:14] <salvarane> screw pitch is 4mm and grear ratio is 1:2
[00:46:31] <SWPadnos> if you don't know some of that information, then you can move the machine to some position, then command a move of say 100mm and measure the real motion
[00:46:53] <SWPadnos> from that, you can calculate the necessary scale
[00:48:36] <salvarane> for example I send the G0 X100 to emc and I measure in real-world the effective movement of the axis ?
[00:50:16] <salvarane> if received 115mm from G0 X100 whath value I set the Variable SCALE
[00:50:31] <SWPadnos> yes
[00:50:50] <SWPadnos> I think new scale = old scale * expected movement / actual movement
[00:51:29] <salvarane> SCALE = (200 * 100 / 115)
[00:53:49] <salvarane> this mode to set the SCALE coordinate , it must make for all the axis
[00:54:04] <salvarane> xyz
[00:54:14] <SWPadnos> do the test on every axis. the numbers may not be the same
[00:54:23] <salvarane> ok
[00:55:55] <salvarane> I thank you
[00:55:58] <SWPadnos> make sure you move to the "starting position" and then measure another move in the same direction - that eliminates backlash from the measurements
[01:03:00] <salvarane> I must measure more than, the same axis in this instance to calculate the average
[01:06:24] <salvarane> domani provo a introdurre alcuni parametri dalla equazione che mi ha dato
[01:06:32] <salvarane> tomorrow I try to introduce some parameters from the equation that it has given to me, gazie of its attendance
[01:07:50] <salvarane> thanks <SWPadnos> of its attendance, good night, tomorrow the beacon to know
[01:09:16] <SWPadnos> good luck with it
[01:10:36] <salvarane> thanks
[04:48:00] <elmo40> would I need to find the servos that suit this controller?
http://qurl.org/251 I don't know if it is for AC or DC motors.
[04:50:50] <elmo40> at $180 I think I will just buy it and slowly find motors that work on it :P Sounds cheap to me. They claim it to be in good shape, 8 out of 10.
[04:59:19] <L84Supper> wow , lots of analog on those boards
[05:00:02] <L84Supper> elmo40: did you find a data sheet for those?
[05:01:35] <elmo40> web search gave me links looping back to that eBay page
[05:02:11] <L84Supper> same here
[05:02:43] <elmo40> and Servo Dynamics is WAY to broad of a term ;)
[05:03:00] <L84Supper> you'd at least need a wiring diagram and a pin-out for the connectors
[05:03:45] <L84Supper> might be by
http://www.servodynamics.com/ but no longer a current part number
[05:06:38] <L84Supper> that ebay seller has lots of crap without any part numbers or product details
[05:08:04] <L84Supper> sp crap/stuff
[05:09:36] <elmo40> they have a brushless servo motor from Parker
http://dnsmp.com/itemphotos/ebay/optiplex/091610_0878.jpg
[05:10:23] <elmo40> but seems like Everything is an 8 out of 10 :P
[05:35:49] <WalterN> JuniperJaxx! hi
[05:36:13] <WalterN> and fjay
[10:35:25] <Paragon39> Hello All... I currently own a pluto-p card and wish to link this to a 3-4 axis mill with stepper drives so as to improve step. Can one also use the PWM out from EMC to control spindle motor speed via an additional Paraport card as I do not beleive the Pluto-p card has enough output functionality to drive 3-4 axis + spindle control? Please correct me if I am wrong.
[10:54:06] <jthornton> if you don't get an answer here for the pluto-p you might try the mailing list
[10:57:40] <jthornton> there also is some topics on the forum about pluto
[11:00:24] <Paragon39> Thanks jthornton
[11:00:32] <jthornton> np
[11:00:57] <jthornton> If I recall the developer of the pluto is on the mailing list
[11:02:34] <Paragon39> It's more an EMC thing really. As I need to know if EMC can control the Pluto-P on say one para port while also generating a PWM for the spindle speed on another para port... if you get my drift ;-)
[11:04:03] <jthornton> ah, yes I'm almost sure you can generate a PWM on the second parallel port, but I know nothing of how the pluto works
[11:05:52] <Paragon39> Thats great news... Im ok with the pluto-P (Got to find those notes) have been playing with it for a couple years on and off but only just now thinking of using it in anger.
[11:52:47] <SWPadnos> you should be able to use a "dumb" parallel port and a pluto at the same time
[12:14:05] <elmo42> it is insane to mix servo and steppers? a friend of mine has a servo driven mill and wants to build a rotary with steppers. I don't know how he will drive it, though :P
[12:14:35] <jthornton> don't rotary's have a steering wheel :P
[12:15:28] <Valen> elmo42: I plan on doing the exact same thing
[12:15:35] <Valen> I cant see any issues
[12:15:41] <Valen> I'm using mesa hardware
[12:35:00] <Paragon39> I bounded this idea about around back... I have part built a rotary table (still in progress) using a stepper and a planetary gear drive (
http://www.motioncontrolproducts.com/gearbox/planetary-gearbox.php?cat=6) if one was to put an encoder on the output of the planetary drive could this be used to negate backlash?
[12:42:25] <Valen> the problem is the motor will build up speed as it moves through the backlash
[12:42:31] <Valen> then it will overshoot out the other side
[12:43:15] <elmo42> just because there is an encoder doesn't mean it is now accurate ;)
[12:43:51] <elmo42> plus, the encoder would be very difficult to put on the output. I don't see how it would work.
[12:45:09] <Paragon39> I see where your both comming from.... just an idea... thanks for the advice :-)
[12:48:25] <Paragon39> How does a backlash of <20 arcmin standup for a homebrew rotary table?
[12:49:15] <elmo42> well, an arcminute is 1/60 of a degree.
[12:49:32] <elmo42> so, that would be less then a 1/3 of a degree backlash
[12:49:36] <elmo42> can you live with that?
[12:51:33] <Paragon39> Is that adequate for cutting gears or do I need a higher resolution?
[12:51:35] <elmo42> all depends on what else you have in the system.
[12:51:50] <SWPadnos> it's about 1/1000 of a turn, if that helps
[12:52:08] <elmo42> that is plenty. as for backlash it shouldn't be much of an issue if you move properly.
[12:52:09] <SWPadnos> put another way, it limits your accuracy to about 0.1%
[12:52:42] <Paragon39> I think I can live with that :-)
[12:54:24] <Paragon39> I currently soldering a ribbon cable to a 25way D for the pluto-p.... Dam awkward...
[12:54:24] <Valen> you can get million point encoders for ~$100-200 on ebay
[12:56:12] <elmo42> that is a lot of points
[13:00:46] <elmo42> here is an inexpensive one
http://qurl.org/451
[13:01:09] <elmo42> Incremental, mind you.
[13:02:45] <elmo42> I like this! 42V Fanuc servo
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120624984398
[13:03:51] <elmo42> only 1Nm, though, but Fanuc. Great name.
[14:08:31] <Paragon39> Is there any plans for EMC to use USB comms to cards such as the 7i43 in the future?
[14:08:48] <SWPadnos> no
[14:09:24] <Paragon39> Is there a technical reason behind it?
[14:09:25] <SWPadnos> if someone can make it work well enough, without losing too much functionality, then a patch would certainly be reviewed for inclusion
[14:09:27] <SWPadnos> yes
[14:09:52] <SWPadnos> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emc2HardwareDesign
[14:13:24] <Paragon39> SWPadnos: Thanks for the link... It just seem that more and more system are produced without the para port these days. USB / Ethernet support would secure compatibility going forward. Just my opinion of course!
[14:13:39] <SWPadnos> it's true. if only it would work
[14:14:26] <psha> SWPadnos: if ethernet so bad? it seem that it have very high troughput so it may satisfy timings
[14:14:28] <Paragon39> What issues have been seen with usb to this point?
[14:14:44] <SWPadnos> throughput and latency aren't the same thing
[14:16:05] <SWPadnos> USB can work for a subset of the features of emc2, but since we prefer to have all features available regardless of your hardware choice, we haven't pursued any (realtime) USB hardware yet
[14:16:11] <psha> SWPadnos: i know... i mean that gigabit ethernet works with pretty low latency
[14:16:43] <SWPadnos> sure, only a few microseconds for a minimum size packet, but then there's the protocol stack and other software in the way
[14:17:05] <SWPadnos> RTNet could work, but there hasn't been a concerted effort to make a HAL driver yet
[14:17:09] <SWPadnos> or hardware for that matter
[14:18:08] <psha> i thought that ip is not that havy in term of 'protocol stack'?
[14:18:23] <psha> at least in one segment
[14:18:30] <SWPadnos> when microseconds count, everything matters
[14:19:02] <SWPadnos> unfortunately, we can't run HAL threads off interrupts (other than the timer)
[14:19:57] <SWPadnos> so there are (potential) issues regarding when a command packet is created vs. when it's sent, when the reply comes back, when HAL sees that data, and then when a new command gets sent
[14:20:36] <SWPadnos> RTNet should eliminate a lot of that, but of course then you need a network card that's supported by RTNet drivers (DEC tulip, Realtek, some Intel I think)
[14:20:58] <Paragon39> I can see the issues now that you put it like that ...
[14:21:16] <SWPadnos> oh, I haven't even started with the real issues yet :)
[14:22:05] <Paragon39> :-) ... Finally just finished soldering the Ribon and 25way for the Pluto-P ...
[14:22:10] <SWPadnos> but since you're already convinced, I can just save the time and stop now ;)
[14:23:09] <psha> :) thanks for the explanation :)
[14:23:43] <Paragon39> :-) ... I'm off to the workshop to test the pluto-p card .... Yes thanks SWPadnos :-)
[14:23:59] <psha> still i think it's a matter of time when ethernet will be used more widely in such environment
[14:24:19] <psha> at least now it has very strong position in HPC (high perfomance computing)
[14:24:23] <SWPadnos> I don't mean to make it sound impossible. it's just a lot of work to support something that doesn't really help much, and actually limits things in other ways
[14:24:37] <SWPadnos> (like limiting features like rigid tapping or other spindle-synchronized motion)
[14:24:39] <psha> and already killed such interconnects as sci and partially mirinet
[14:25:34] <skunkworks> is it friday finally?
[14:35:08] <psha> SWPadnos: rtusb seem to be pretty dead?
[14:35:16] <SWPadnos> seems to be
[14:40:04] <psha> SWPadnos: btw is it possible to send hal pin changes over network?
[14:40:29] <SWPadnos> I think someone made a program to do that, but I don't remember for sure
[14:40:31] <psha> or only nml commands
[14:40:41] <SWPadnos> it's non-realtime though, like userspace HAL components
[14:41:05] <psha> i understand, but using control pc for camera processing is not good too
[14:41:55] <SWPadnos> it shouldn't matter. emc isn't much of a resource hog, and the camera system shouldn't affect RT latency (if it does, you probably have other problems too)
[14:43:55] <psha> camera creates large data stream through boards i/o
[14:44:30] <SWPadnos> if it has a crappy driver that screws up RT latency, then a separate PC is a good idea :)
[14:45:00] <SWPadnos> you shouldn't need a multi-megapixel camera, something in the 1024x768 or 1280x1024 range should be good enough
[14:45:00] <psha> i'm not confident in camera drivers so i'll better suspect worse cases :)
[14:45:09] <SWPadnos> sure, test it out and see what happens
[14:48:04] <psha> hm... uvc over uspip is not rock solid solution...
[14:48:12] <psha> usbip
[15:53:39] <dave_1> is there something inherent in emc that puts a lower limit servo cycle frequency?
[15:54:03] <dave_1> I can get movement at 200 Hz but it locks up at 100 Hz
[15:55:48] <dave_1> no response from gui
[15:56:32] <dave_1> 200 may be a resonance because it growls ... but then again it may just that ragged.
[15:57:17] <SWPadnos> have you also slowed the task cycle and/or GUI refresh cycles?
[15:57:42] <dave_1> no ..they are at 0.01 IIRC
[15:57:57] <SWPadnos> same as servo - coincidence? :)
[15:58:13] <dave_1> could be ..
[15:58:35] <dave_1> I'll try slower gui and see what happens
[15:58:45] <SWPadnos> and task
[15:58:53] <SWPadnos> that may be the more important one
[15:58:58] <dave_1> probably a good idea.
[15:59:07] <SWPadnos> I don't see why it should lock up, but I can see it performing strangely
[15:59:57] <dave_1> the strangely happened at 8KHz ... would work for a while but then parts of the gui just quit working
[16:00:26] <dave_1> pretty solid at 4KHz with a 1200 MHz Duron
[16:00:45] <dave_1> I'll play and get back to you .... thanks.
[16:02:28] <skunkworks> I read that twice and don't know what you guys are talking about
[16:02:53] <SWPadnos> SERVO_PERIOD
[16:03:03] <skunkworks> 100hz?
[16:03:13] <SWPadnos> apparently, dave had trouble when he made the servo cycle 100 Hz or slower
[16:03:15] <SWPadnos> yeah
[16:03:44] <psha> man please may you describe me in brief how is servo controlled?
[16:03:53] <psha> if it's not hard to explain to dummy :)
[16:04:00] <skunkworks> even our k&t had a 250hz servo loop. ;)
[16:04:06] <psha> how stepper is controlled i understand
[16:05:43] <SWPadnos> http://en.wikipedia.org/wiki/PID_controller
[16:06:03] <psha> thx
[16:07:29] <psha> i'll have to correct my question
[16:08:28] <psha> I thought that servo control is performed via PWM signal which sets servos position in some range (e.g 0-180 degrees)
[16:08:49] <SWPadnos> those are RC servos, not servo motors
[16:09:14] <SWPadnos> (Radio Control - often used in airplanes or that kind of thing)
[16:09:17] <psha> May you throw a link to servo motors?
[16:09:30] <psha> Yea, only kind of 'servo' things i seen :)
[16:09:33] <SWPadnos> you can google for one, like I would :)
[16:09:43] <psha> so i'll do
[16:09:44] <SWPadnos> servo motor control ...
[16:11:36] <psha> It seem that servo motor is 'motor + encoder' pair and even type of motor is not that important?
[16:11:58] <SWPadnos> actuator and feedback, yes
[16:12:07] <psha> Sorry for dumb questions but I realy have no background in this :)
[16:12:09] <SWPadnos> could be a resolver or tachometer
[16:13:53] <skunkworks> or in a rc servo - potentiometer(sp)
[16:14:16] <skunkworks> or atleast that is what they used to be.
[16:18:47] <psha> so for example actuator may be stepper motor so we have to send standard pulses to it?
[16:22:47] <SWPadnos> steppers suck as servos, for the most part
[16:23:39] <SWPadnos> if you look at PID control, it relies on the motor actually having extra torque available when needed, which steppers don't
[16:24:02] <SWPadnos> steppers have decreasing torque as they spin faster, so you can never use any "reserve" to catch up if the motor falls behind
[16:24:13] <SWPadnos> once the motor has fallen behind, it's already lost
[16:25:27] <Jymmm> SWPadnos: "steppers have decreasing torque as they spin faster" Is the inverse true for servos?
[16:25:31] <psha> and cards like mesa just implement this pid control in fpga so emc don't need to bother with it?
[16:25:44] <SWPadnos> Jymmm, no, servos have constant torque regardless of speed
[16:25:51] <Jymmm> SWPadnos: ah
[16:25:53] <SWPadnos> psha, no, emc does the PID
[16:26:39] <Jymmm> Isn't the mes and the like to be able to get the commands out of the computer in a timely manner?
[16:26:53] <Jymmm> Isn't the mesa and the like to be able to get the commands out of the computer in a timely manner?
[16:27:17] <SWPadnos> they relieve the CPU from the task of generating a PWM or other analog control signal, and also from counting fast encoder feedback
[16:28:04] <Jymmm> I thought it was to bypass the speed limitation of Paraport (for one)
[16:28:31] <SWPadnos> yeah, by relieving the CPU of the burden of generating PWM and counting encoders ...
[16:29:03] <Jymmm> SWPadnos: I thought that ALL paraport had some 2ms limitation
[16:29:05] <psha> SWPadnos: thanks a lot for explanation :)
[16:29:17] <SWPadnos> psha, sure
[16:29:20] <SWPadnos> Jymmm, ?
[16:29:34] <SWPadnos> (0.5-1 microseconds per output)
[16:29:54] <Jymmm> SWPadnos: something about 2 cycle
[16:30:11] <SWPadnos> eh. dunno
[16:30:25] <Jymmm> lol
[16:30:46] <Jymmm> Ok, other than limited I/O, what other limitation does paraport have?
[16:31:18] <Jymmm> (it was something todo with timing iirc)
[16:33:06] <psha> About parport, what mode I need to set in bios for onboard parport?
[16:34:27] <psha> EPP? ECP?
[16:36:28] <psha> Btw who is responsible for ubuntu packages of EMC2?
[16:37:41] <Jymmm> ubuntu
[16:38:50] <skunkworks> Jymmm: the mesa hardware counts the encoders and generates the pwm. With the printer port - emc is doing it.
[16:39:57] <psha> Jymmm: i meat emc2 packages for ubuntu :)
[16:40:27] <Jymmm> skunkworks: No, no, I was speaking of the "limitation" of paraport... something todo with timing of cycle counts (can't send faster that x in two cycles or something like that)
[16:40:40] <skunkworks> so - in effect emc has to bit-bang the printer port to genterate pwm - while with the mesa hardware - emc just sends it the value it wants the pwm to be at. emc says 50% and the mesa outputs a 50%dc pwm signal
[16:41:23] <skunkworks> it is more of a limit of emc and computer latency
[16:42:05] <skunkworks> if your latency is 10us - you will never output a signal faster than twice that. (I may be winging it here)
[16:42:28] <SWPadnos> Jymmm, there are (at least) two limitations: first is absolute speed (not much of a limitation) - the CPU has to do two OUT instructions to make one step pulse (set high, set low), and those OUT instructions take between 0.5 and 1.2 microseconds each, during which time the CPU is halted (losing millions of cycles, at the GHz speeds of today)
[16:42:43] <psha> At least i've got clean build of emc2 for control pc...
[16:43:35] <SWPadnos> the second limitation is latency. the CPU can't control the timing of any step better than the latency measurement. so if you want a step at time t=11.5 uS, and your latency is 15 uS, you'll either get one at t=0 or t=15, but not at t=11.5
[16:43:51] <SWPadnos> psha, standard or EPP. EPP if you want to use the data pins as inputs instead of outptus
[16:43:55] <SWPadnos> outputs
[16:44:13] <psha> thanks
[16:44:58] <Jymmm> SWPadnos: That was it the 2 cycle (hi/lo) of <2ms limitation I couldn't recall the details. See, I'm not crazy (much)
[16:45:07] <SWPadnos> microseconds, not milliseconds
[16:45:18] <SWPadnos> and yes, you are much crazy :)
[16:45:29] <SWPadnos> back to work for me. have fun
[16:45:52] <Jymmm> Ok fine, uS. and no more than you on the crazy part =)
[16:47:00] <dave_1> hey swp ....?
[17:23:24] <salvarane> Thanks <SWPadnos> I have resolved the problem's SCALE on my cnc router
[17:53:30] <Paragon40> Hello All... I am seeing an issue with pluto step... when I make an x and y (up arrow) move everything is ok but if I make a y down arrow move I get an joint2 following error. Additionaly I notice that the cone int the graphic display in axis moves slightly up it also move the Z axis up by a tiny amount before the joint2 following error!
[17:54:29] <Paragon40> The release I am using is dev 2.5.0~pre
[18:05:19] <elmo42> seems like they are still alive. Latest release was April 2010.
http://sourceforge.net/projects/rtnet/
[18:05:46] <elmo42> but my question is... what do I connect on the other side of the cable? sure, I have a NIC that is supported but where do I go from there?
[18:06:54] <elmo42> to connect with more then one device I would need a switch or router... that would add latency issues.
[18:07:49] <elmo42> I wonder who uses this.
[18:08:38] <cpresser> elmo42: ist quite standart in industrial automation
[18:08:45] <cpresser> many SPS-Systems use ethernet
[18:08:48] <Jymmm> You use a HUB, not a switch or router.
[18:09:17] <cpresser> there was even a post on the mailinglist about such a setup..
[18:09:41] <cpresser> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Etherlab
[18:09:56] <elmo42> sure they use ethernet, but RTNet?
[18:15:43] <MattyMatt> a switch would be OK wouldn't it? there's no delay in those?
[18:16:43] <cpresser> switches do store-and-forward, they have internal buffers.
[18:17:03] <cpresser> so they do have a slight delay.
[18:17:42] <cpresser> a switch looks into the packet, looks up the MAC adress and forwards the packet to the targetport
[18:18:22] <SWPadnos> hubs also have a delay of 92 bit times
[18:18:36] <SWPadnos> for 10/100 anyway (I don't know if there are gigabit hubs)
[18:18:56] <Paragon39> Hello All.... I posted this recently but have just moved back to my comfy warm office and am not sure if there was any replies... Hello All... I am seeing an issue with pluto step... when I make an x and y (up arrow) move everything is ok but if I make a y down arrow move I get an joint2 following error. Additionaly I notice that the cone int the graphic display in axis moves slightly up it...
[18:18:58] <Paragon39> ...also move the Z axis up by a tiny amount before the joint2 following error!
[18:40:39] <skunkworks> Paragon39: what version of emc are you running?
[18:41:59] <Paragon39> I downloaded the latest branch 2.5.0-pre and run it inplace . I have older trunks on the system also.
[18:42:57] <skunkworks> ok
[18:43:18] <MattyMatt> cpresser ah I thought your description of a switch was a router, and a switch was like a managed crossbar
[18:43:35] <skunkworks> so - x is the only axis that works?
[18:43:36] <Paragon39> I saw this same issue in back in 2007 but for the life of me I cant remenber how I fixed it. The problem appears that axis1 down interferes with axis2
[18:45:54] <Paragon39> Sorry no .... X and Z work as they should.... Y works in one direction (up key) the Y down key makes an up move on the Z axis. Both physicaly and is also displayed in the backplot as an Z up move. The the axis2 following error occurs.
[18:46:16] <skunkworks> oh - that sounds like a config issue
[18:48:22] <Paragon39> Yes from memory it was... I think I had to change a c file and recompile but jeez my memory. The only other possibility is that 2.5.x is taking configs from the previous branches but I used the ". scripts/emc-enviroment" ... ?
[18:51:03] <cpresser> Paragon39:
[18:51:13] <cpresser> paste your ini-file into a pastebin
[18:51:24] <cpresser> we take a look at t, and see if we can help :)
[18:51:33] <psha> EtherCAT has nice approach to switch/hub problem :)
[18:51:55] <cpresser> psha: its a chain?
[18:52:33] <psha> not strict chain but looks like
[18:52:41] <Paragon39> cpresser: Thanks for the offer... This happens on the default pluto_step_inch.ini
[18:53:02] <psha> it may be tree if device has several outputs
[18:53:22] <psha> they state that datagram is processed 'online' while retransmitting further
[18:54:25] <cpresser> so all data is seen by all devices
[18:54:35] <cpresser> like a DMX-bus or similar
[18:54:38] <psha> Since the communication utilizes a logical (and thanks to full-duplex Fast Ethernet also physical) ring structure
[18:56:19] <psha> The communication with 100 servo axes is also extremely fast: every 100µs, all axes are provided with command values and control data and report their actual position and status.
[18:57:29] <cpresser> thats like 10kHz, thats quite fast, yes :)
[18:59:05] <skunkworks> Paragon39: I don't see anything wrong with the pluto_pinout.hal in git
[18:59:51] <psha> cpresser: it's from ethercat cite so they took only best results :)
[18:59:58] <psha> s/cite/site/
[19:00:21] <cpresser> they want to sell their stuff.. its quite expensive
[19:00:34] <cpresser> but its intended for industrial automation, so its okay :)
[19:01:04] <Paragon39> Me neither the pinouts appear to be ok I think it's in the driver c code... I maybe getting interference from the older trees so I will try it with a live cd and see how that looks.
[19:04:19] <psha> maybe sometimes retransmission chips for ethercat will be cheep so it would be usefull in hobby...
[19:18:57] <skunkworks> Paragon39: jepler would be the one to ask - I am sure he is the one that helped you last time. (if there was a bug - but I would thing that would have been fixed in trunk atleast)
[19:20:53] <Paragon39> skunkworks: Jepler did help last time. Ive just moved all the old versions of EMC out so I am only left with 2.5.0-pre but am still geting the same problem. Is there away to debug?
[19:21:36] <skunkworks> that is above my knowledge base :)
[19:24:41] <Paragon39> NP thanks for help skunkworks :-)
[19:24:54] <cpresser> Paragon39: perhaps hal-scope? at least it shows you what happens inside emc :)
[19:27:27] <Paragon39> cpresser: Good point I forgot about that :-)
[19:29:51] <skunkworks> Paragon39: do you have some negative scale values for any of the axis's?
[19:32:49] <Paragon39> I dont think its that skunkworks as the Y down move actually shows as an Z move in backplot... It changes the Z value number in the backplot, as well as actually making a physical move on the Z axis of the mil.
[19:36:52] <Paragon39> Hal Scope also shows a trigger on the "axis.2.motor-pos-cmd" when the Y down key is pressed it should be triggeringthe "axis.1.motor-pos-cmd"
[19:37:59] <skunkworks> can you post your hal files? that doesn't make sense
[19:38:06] <skunkworks> and ini?
[19:38:42] <Paragon39> skunkworks: there the default ones from the 2.5.0-pre release
[19:39:16] <skunkworks> humor me?
[19:39:35] <Paragon39> OK where shall I post them?
[19:39:49] <Jymmm> skunkworks: A frog walks into a bar...
[19:39:59] <skunkworks> pastebin.ca
[19:40:08] <Jymmm> http://codepad.org
[19:40:09] <Paragon39> ok...
[19:46:21] <Paragon39> http://pastebin.ca/1952814 pluto_step.ini
[19:47:38] <Paragon39> http://pastebin.ca/1952815 the hal file
[19:48:22] <skunkworks> looks right
[19:48:24] <skunkworks> ;)
[19:48:51] <skunkworks> can you command a move in y with mdi
[19:49:07] <Paragon39> trying now
[19:52:12] <Paragon39> OK same issue... Home all axis's... g0 y1 worked fine then y0 moved the z up by .400 then joint 2 following error.
[19:53:31] <skunkworks> odd. I do not know
[19:56:37] <Paragon39> As I said I had this issue around 2007 when I first started playing with the pluto-p. Im sure I made some code chage and then recompiled but for the life of me I cant remeber. I just found a very old post that I posted on the matter back in 2007
http://www.cnczone.com/forums/emc_linux_enhanced_machine_control/45250-emc_pluto-step_z_y_axis_interference_bug.html
[19:57:20] <skunkworks> I was looking though the irc history for something also - and found none.
[19:58:09] <Paragon39> Really... can you search on username posts?
[19:59:06] <Paragon39> I thinking it could be the pluto-step.write
[20:03:03] <skunkworks> I would assume it was the pluto_step.comp
[20:03:24] <Paragon39> hehehe ... looking at it now
[20:03:28] <skunkworks> http://www.google.com/#sclient=psy&hl=en&q=%22pluto_step%22+site:http%3A%2F%2Fwww.linuxcnc.org%2Firc%2Firc.freenode.net%3A6667%2F&aq=f&aqi=&aql=&oq=&gs_rfai=&pbx=1&fp=6b964bcc94c5a63
[20:03:54] <skunkworks> I don't think the search works perfectly
[20:08:53] <Paragon39> Thanks for that link skunkworks ... I cant find anything relating to my username and pluto. I must have used a different username back then 2007
[20:10:11] <skunkworks> heh
[20:10:21] <skunkworks> I have found it to be hit or miss
[20:11:08] <Paragon39> Oh I did a search for paragon but only got results for around 2008
[20:13:15] <Paragon39> Found something ...
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2007-10-15.txt then searched for paragon time 11:28:49
[21:27:35] <skunkworks> seb: !
[21:30:51] <seb_kuzminsky> hey there :-)
[21:39:13] <micges> hi seb
[21:39:58] <Paragon39> Still no Joy :-(
[21:41:49] <micges> seb_kuzminsky: does hostmot2 supported mesa cards listed somewhere?
[21:47:56] <bootnecklad> oh lawd
[21:47:58] <bootnecklad> [22:48] <bootnecklad> Some misspellings are quite fun
[21:47:59] <bootnecklad> [22:48] <bootnecklad> they add unique...
[21:48:01] <bootnecklad> [22:48] <bootnecklad> ...character
[21:49:17] <seb_kuzminsky> micges: first paragraph of the hostmot2 manpage ;-)
[21:49:35] <Paragon39> I could certinlee do with spill chicker in me irc client ....
[21:49:35] <seb_kuzminsky> or do you mean daughter cards?
[21:50:04] <micges> both
[21:50:17] <micges> I mean 3x20 with motherboard card
[21:50:25] <micges> and so on
[21:50:39] <seb_kuzminsky> ah oops, the 3x20 is missing from the list
[21:51:15] <seb_kuzminsky> a list of supported daughter cards is a good idea
[22:19:53] <salvarane> hello
[22:21:43] <salvarane> sorry , I proved to configure jpypad for emc2 2.4.0 version , I insert into at end of the file standard_pinout.hal this string
[22:21:50] <salvarane> loadusr hal_input -KRAL /dev/input/js0 Vendor=0x0079 Product=0x0011
[22:22:59] <salvarane> when I rung emc on the terminal appear this message
[22:23:13] <salvarane> No input device matching '/dev/input/js0' was found (1 devices checked)
[22:26:08] <salvarane> I read this wiki
http://wiki.linuxcnc.org/emcinfo.pl?Using_A_Joypad_To_Jog_And_Control_Spindle_Speeds
[22:27:24] <salvarane> But this wiki contain much of the option that for me not is necessary
[22:29:43] <salvarane> somebody can indicate to me a guide doc minimal for configure the joypad for emc 2.4 version please
[22:32:27] <Connor> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Simple_Remote_Pendant
[22:33:16] <Connor> That's what I use. Works just fine.
[22:36:52] <salvarane> this configure mode it is ok with emc 2.4 version ?
[22:38:22] <Connor> That's what I'm running.
[22:38:35] <Connor> with 10.04
[22:40:10] <salvarane> sorry you have patience ; I have this joypad " idVendor 0x0079 DragonRise Inc."
[22:41:32] <salvarane> in place of " Dual " on this string "loadusr -W hal_input -KRAL Dual" what I must put please
[22:41:49] <Connor> What's it's name?
[22:42:02] <Connor> less /proc/bus/input/devices
[22:42:07] <Connor> and find the Name= line for the pad.
[22:42:13] <Connor> use just one word from that.
[22:43:08] <Jymmm> jepler: ping
[22:45:26] <salvarane> the name is "USB Gamepad " on line name = I can set with one of the two USB or Gamepad it is correctly
[22:45:50] <Connor> Use Gamepad
[22:46:03] <salvarane> ok thanks
[22:51:33] <Paragon39> jepler: Are you available at the moment?
[23:08:39] <salvarane> I followed the guide Simple_Remote_Pendant but the joypad not move the axis
[23:08:51] <salvarane> the emc run without errors
[23:14:54] <Connor> hold one of the buttons (A,B,C) while using the joystick.
[23:19:05] <salvarane> in the graphical windows on emc2 in it not looked to move no axis
[23:20:03] <Connor> machine has to be on, you press a button on the gamepad, and move the stick.. you may have to redefine your axis or somrthing.
[23:21:11] <salvarane> sorry but in this moment I have the machine in an other place
[23:23:01] <salvarane> is possible understand , if the joypad work withouth with the machine is connect on pc
[23:24:09] <salvarane> sorry, is possible understand , if the joypad work withouth that the machine is connect on pc
[23:24:20] <salvarane> ?
[23:26:40] <Connor> I'm not sure I understand.. but.. you have to have the power button in the EMC software toggled to on and set the screen to manual (as If you were going to JOG using the GUI), other than that.. I think you might need to go in and make sure you have your buttons and axis defined correctly.
[23:29:23] <salvarane> ok the emc is ready to work all the button are ok I have fixed the home for axis
[23:30:01] <Connor> okay, so, push the 1,2, or 3 button on the game pad, and while pushing it.. move the left joystick.
[23:31:37] <salvarane> I don't see any movement
[23:31:57] <Connor> okay, so, follow the debug info in that wiki to see the inputs for you joystick...
[23:32:07] <salvarane> ok
[23:33:40] <salvarane> this is the location just
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?HereIsHowToCheck
[23:39:09] <salvarane> into the window halcmd: loadusr halmeter not appear the Gamepad.axis and other options
[23:48:09] <salvarane> ok I have understand use the halmeter for configure all pin into configure file .hal
[23:48:12] <salvarane> thanks
