Back
[00:01:49] <Roguish> hey all, is there a pin, parameter, or signal for the current feed rate? i've looked, but cannot seem to find one.
[00:02:25] <jmkasunich> I don't think so
[00:06:59] <Roguish> seems like it's gotta be a variable somewhere? in motion?
[00:07:31] <jmkasunich> it gets complex when you consider that you might have angular feeds and linear feeds at the same time
[00:07:40] <jmkasunich> is it in/min, or deg/min
[00:08:11] <Roguish> ok, sure, how about whatever is read in from Fxxx in a gcode file?
[00:09:37] <jmkasunich> that has the same issue (which is why it is recommended to use inverse time when doing mixed angular/linear moves)
[00:12:05] <Roguish> well, i just would like to display the current f
[00:12:26] <Roguish> F rate in big numbers in a pyvcp.
[00:12:45] <jmkasunich> if its a three axis machine, thats not hard
[00:13:02] <Roguish> that' s all i have at the moment.
[00:13:15] <jmkasunich> send x, y, z, pos thru ddt blocks to get x, y, z velocity, then send thru a hypot block to merge the three
[00:13:20] <Roguish> root of the sum of the squares?
[00:13:29] <jmkasunich> thats what hypot does
[00:13:49] <jmkasunich> I think one (or more) of the sim configs has that setup already
[00:14:15] <Roguish> so, that will give me the current velocity. how about the feed rate as read in?
[00:14:38] <jmkasunich> you mean before feed override, etc?
[00:14:44] <jmkasunich> that will be a lot harder to get
[00:14:44] <Roguish> yes.
[00:15:23] <Roguish> it's read in, isn't it stored somewhere?
[00:15:23] <Roguish> or could be?
[00:15:42] <jmkasunich> it is in the data that is passed to the motion controller
[00:15:52] <jmkasunich> but extracting it isn't trivial
[00:16:55] <Roguish> should i put in a 'feature request'?
[00:17:11] <jmkasunich> if you want
[00:17:32] <jmkasunich> be sure to put in the "why I want this"
[00:17:48] <jmkasunich> gotta convince people that it is usefull
[00:18:07] <Roguish> ok, i'll see what i can do. thanks for the help.
[00:46:26] <elson> hello, guys, trying to set up my demo for the Workshop!
[00:49:49] <elson> Good GAWD, Jeff, I see you added this test for the parport register address SEVEN MONTHS ago, it seems there is a problem. I get the error message "PPMC: ERROR: invalid port_addr: 378"
[00:51:45] <elson> I'd swear I downloaded and tested from CVS since then, but maybe not. Anyway, any comments on what could be wrong? I rmmod'ed ppdev, lp and parport with no effect. I specified the port addr in the loadrt command, no effect.
[00:53:06] <jepler> maybe the leading 0x indicator for hex is required? 0x378
[00:53:35] <jepler> er, no, that's probably not it
[00:53:56] <elson> Yes, I specified it as loadrt hal_ppmc port_addr="0x378"
[00:54:20] <elson> I get the same message when it defaults to the hard-coded default
[00:54:36] <jepler> if you just want to get on with life you can remove just that change and see if it fixes things:
[00:54:39] <jepler> cvs up -j1.52 -j1.51 hal_ppmc.c
[00:54:45] <jepler> (in the src/hal/drivers directory, then recompile)
[00:55:05] <jepler> (if you're compiling yourself, that is)
[00:55:53] <jepler> I see that change is in all the 2.2.x versions too
[00:56:08] <elson> OK, thanks for that bit of CVS magic, but if you can make some guesses to what is wrong, it would be far better to fix it and commit a fix.
[00:56:42] <elson> I would be willing to spend an hour or so to get it working right and then commit the fix.
[00:56:52] <jepler> do you have just one bus on this system?
[00:57:42] <elson> Just the one standard on-mobo parport on that system. I have added a PCI parport to my server machine, and do board testing with it. It is a BDI descendant.
[00:58:57] <jepler> can you cat /proc/ioports and put it in pastebin.ca?
[00:59:11] <elson> Sure, give me a minute....
[01:00:19] <jepler> just let me know the url when it spits it back out
[01:01:54] <elson> Hmmmm, verrry interesting. cat /proc/ioports causes a segment violation! Even with sudo. Uhhh, maybe I should reboot?
[01:02:41] <jepler> yes, that's likely to clear it up
[01:07:00] <jepler> there's something I do in probe_parport that can lead to that .. did you use probe_parport while working on this?
[01:10:33] <elson> Mm, very odd. after reboot, not only does cat /proc/ioports work normally, but the ppmc driver now seems to work OK, too.
[01:11:10] <elson> I did some lsmod and rmmod commands to remove several drivers.
[01:11:28] <elson> This boot, I didn't have to mess with any drivers.
[01:11:29] <jepler> not too big a surprise: the data structure that rtapi_reserve_region looks at is the same one that is used to print /proc/ioports so if it is screwed up it might lead to both of those results
[01:11:44] <jepler> run emc a few times and see whether the error returns ..
[01:12:01] <elson> I do get a RAFT of shmctl : invalid argument messages, I'll have to see what that is about.
[01:12:44] <elson> OK, I had loaded and shut down the older version of EMC2 a number of times while tweaking the hal files to make the spindle speed control work.
[01:14:32] <elson> By the way, do you know how to do a type conversion in hal? There seems to be a conv_s32_float conversion fuction, but I can't find any docs on how to specify it.
[01:16:02] <jepler> elson: I think you'd add something like this in a hal file: loadrt conv-s32-float count=1 / addf conv-s32-float.0 servo-thread / net your-integer-signal => conv-s32-float.0.in / net your-new-float-signal <= conv-s32-float.0.out
[01:16:53] <elson> Oh, to correct an earlier statement, I restarted the current version of EMC2 a number of times when it was rejecting the parport address, too.
[01:17:06] <jepler> (consider thread order when you choose where to 'addf')
[01:17:11] <elson> OK thanks for the info on the conversion function, will have to try it.
[01:18:09] <jepler> elson: conv-s32-float doesn't apply scaling, you can use a 'scale' component for that.
[01:18:49] <elson> OK, I was going to use mult2, but I guess the scale function would do the same.
[01:18:58] <jepler> yeah that works too
[01:19:32] <jepler> on this fresh boot, has emc restarted properly a few times?
[01:20:28] <elson> OK, well, I will probably be re-starting EMC a number of times, but I have not doen that yet. I want to play with it a bit first, and try out the G33.1 function.
[01:21:14] <elson> I will certainly let you know if this wierdness shows up again.
[01:21:28] <jepler> I appreciate it.
[01:22:11] <elson> OK, I'm doing this on a different computer, so I will get off IRC for a while. I'll send a message later, one way or the other.
[01:22:19] <jepler> OK
[01:22:19] <elson> And, thaks for the help!
[01:22:22] <jepler> see you later
[01:39:39] <elson> Hello, Jeff, I've got one really up your alley right now.
[01:40:58] <elson> In Axis, if you set the spindle running with M03 S750, and then go to manual, it stops the spindle. Then, in manual, when you hit the spindle run buttons on screen or F10/F11, you get a motion.spindle-out value of +1 or -1, instead of the +/- 750!
[01:47:09] <jepler> elson: you might be interested in the change that was recently made to improve spindle when switching modes .. let me dig you up a reference to the mailing list post about it
[01:48:45] <jepler> http://thread.gmane.org/gmane.linux.distributions.emc.user/7580/focus=7581
[01:49:02] <jepler> er maybe
http://article.gmane.org/gmane.linux.distributions.emc.user/7581
[01:49:19] <jepler> using emc2 from June 4 or later and the new inifile line you may be happier with the behavior
[01:50:22] <jepler> (TRUNK)
[01:54:49] <elson> OK, I see that every time you stop the spindle, you have to step up the speed again with the + button. Works, but kind of inconvenient.
[01:57:16] <elson> Well, I'm not sure those options are all that safe. The problem here is that the manual mode sets the speed back to 1 RPM every time you hit stop.
[01:58:01] <elson> I'd much rather it left the speed at whatever the last S word set it in MDI or programmed run.
[01:58:51] <elson> I just did the first G33.1 and it did reverse the spindle and back out. I'm still cutting air, but will try it in real metal soon.
[01:59:47] <elson> Thanks, again!
[02:06:17] <jepler> welcome, again
[03:04:09] <cradek> elson: that might have been the first rigid tap on ppmc.
[03:05:26] <cradek> I also don't care for the manual spindle control. alex's fix is fine, I think. You can MDI S250M3 and then switch to manual to cut with the jog keys for instance
[03:05:42] <cradek> (in pure manual mode, there's no way to get S250)
[03:05:57] <cradek> you can get 201 or 301, iirc.
[05:58:46] <elson> Well, I got it working, to some extent, but it is mangling the threads at the top of the hole. After shutting it down, It ocurred to me that the tap returns to the starting Z coord, but it has to decelerate at the end of the move, so it starts decelerating before the tap is out of the hole, mangling the top thread or two. I am using a combination drill-tap, so I drill at slow feed, then start the G33.1 tapping operation.
[06:00:03] <elson> What I will try tomorrow is to drill through first, back up and then do the G33.1 with the tap section farther up. This will make the retract cycle also come farther up before decelerating. I have fair confidence this will fix it!
[06:01:31] <elson> And, yes, I suspect this may be the first rigid tapping with the PPMC driver, and most likely with the UPC board. Stuart Stevenson may have done rigid tapping on his machines, which use the PPMC board set.
[06:02:09] <elson> Signing off for the night! Thanks for the help!
[14:34:18] <CIA-32> EMC: 03jepler 07v2_2_branch * 10emc2/docs/src/gcode/main.lyx: m66 is both digital and analog
[14:34:43] <CIA-32> EMC: 03jepler 07TRUNK * 10emc2/docs/src/gcode/main.lyx: from branch: m66 is both digital and analog
[15:13:56] <alex_joni> jepler: thanks ;)
[22:14:46] <BigJohnT> http://imagebin.ca/view/BXU9ULrt.html
[22:14:58] <BigJohnT> http://pastebin.ca/1042389
[22:15:22] <BigJohnT> seems to be a bit of a bug in the G64 Pnn when run on larger arcs
[22:16:05] <BigJohnT> the bottom two were run with G64 and the first two arcs are funky
[22:16:29] <BigJohnT> the rest were run with G61 and cut fine...
[22:18:25] <BigJohnT> removed extra line feeds on this one
http://pastebin.ca/1042392
[22:19:05] <BigJohnT> and the parts came out like the plot...
[23:02:23] <BigJohnT> I guess someone fixed it all ready as I don't get the same error down here in the beer cave
[23:02:52] <BigJohnT> I'll have to drag the other computer down here and get the latest on it and try again
[23:55:47] <jmkasunich_> jmkasunich_ is now known as jmkasunich