#linuxcnc-devel | Logs for 2014-05-07

[08:36:00] <skunkworks> logger[psha]:
[08:36:00] <logger[psha]> skunkworks: Log stored at http://psha.org.ru/irc/%23linuxcnc-devel/2014-05-07.html
[08:36:34] <skunkworks> cradek: http://imagebin.org/309526
[08:36:52] <skunkworks> I wonder if the torture program should move any random number of axis at once.. the uvw don't seem to get up to the top speed..
[08:37:03] <skunkworks> (they where 1,2 and 3 in/s respectivley)
[08:37:10] <skunkworks> the rest of the axis seem to peak out at some point
[08:37:19] <skunkworks> but that being said - I think the new tp is as tested as it can be...
[09:05:14] <Robert302> Hello, i am totally new in developing community project. I worked as a C software developer for two years and now I'm working since 5 months on a project with LinuxCNC.
[09:05:15] <Robert302> I have a 3 axis machine for measuring magnetic fields with a 3D HAL-Sensor. I've developed a data logger as a linuxcnc hal module for recording measurements to send them via tcp to MATLAB or octave. The datalogger is written very basic so that everybody could use this part of software in future projects. I wan't now ask you how i should commit my code and what kind of documentation do you need. It would be nice to give me a short help. ..
[09:26:08] <cradek> hi robert
[09:26:17] <cradek> do you have a public git or similar we can look at?
[09:26:43] <cradek> sounds like an interesting project
[09:59:15] <skunkworks> logger[psha]:
[09:59:15] <logger[psha]> skunkworks: Log stored at http://psha.org.ru/irc/%23linuxcnc-devel/2014-05-07.html
[09:59:32] <cradek> skunkworks: I didn't understand what you meant
[10:00:11] <skunkworks> cradek: heh. shocker. :)
[10:00:50] <skunkworks> the uvw axis don't seem to reach their maximum velocity with the path generated
[10:01:06] <cradek> you think it is always constrained by xyz?
[10:01:20] <skunkworks> (I have the gcode feedrate set to something huge)
[10:01:27] <skunkworks> or rotory?
[10:02:29] <skunkworks> in the screenshot - the uvw max velocity is set to 1,2,3 - you can see that v and w never reach it.
[10:03:45] <skunkworks> the rest of the axis seem to peak out.
[10:03:54] <cradek> it also never makes something like a Y-only move
[10:04:01] <skunkworks> right
[10:04:22] <skunkworks> that was my comment - maybe random multible of moves - 1 - 9
[10:04:49] <skunkworks> 1 though 9 axis moves
[10:07:12] <skunkworks> if that made sense
[10:12:40] <cradek> hm, that will sometimes give rotary-only moves
[10:12:56] <cradek> they will have a lower feed rate because feeds were never in degrees before
[10:13:18] <cradek> maybe I should always use inverse time feed
[10:14:40] <cradek> I also notice we're not really testing anything but path following (by looking at the results compared to the AXIS preview) and axis constraint violations
[10:14:59] <cradek> no idea whether this "G3 F240" line runs at 240
[10:15:07] <skunkworks> right
[10:15:40] <skunkworks> well - you might be able to test requested feed with actual feed?
[10:15:56] <skunkworks> but the feed may never be reached with a given segment..
[10:15:58] <cradek> the motion involving many of the alternate axes is so weird it's hard to even tell whether it's even right
[10:16:10] <cradek> yeah you could watch the requested feed hal pin
[10:16:23] <skunkworks> you could check to see if the requested feed isn't over actual path feed I suppose
[10:16:24] <cradek> but again that's hard with rotaries
[10:16:30] <skunkworks> right
[10:19:08] <cradek> for instance the cyan path is a G0: http://timeguy.com/cradek-files/emc/how-can-that-be-one-move.png
[10:19:29] <cradek> how am I supposed to see whether that's right
[10:22:43] <KGB-linuxcnc> 03Chris Radek 05master 97ff1b7 06linuxcnc 10scripts/torture.py Don't always have XYZ in the straight moves * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=97ff1b7
[10:34:48] <seb_kuzminsky> cradek: if you used sai to generate a list of the canonical motion commands for the program, then ran the program and used halsampler to record axis.*.joint-pos-cmd, you could compare the two, i think
[10:35:26] <seb_kuzminsky> verify that each point in the motion controller's output is within G64P-word of the canonical path
[10:35:34] <cradek> hm, it's true there's also motion-line
[10:36:26] <seb_kuzminsky> that test is what i'm trying to write for robert ellenberg's tp
[10:36:56] <seb_kuzminsky> does that seem sane, or am i missing something?
[10:37:13] <cradek> "within tolerance of the path" seems hard to write
[10:38:06] <seb_kuzminsky> the distance between a point and a line is easy to compute
[10:38:49] <seb_kuzminsky> for point-to-arc i'm thinking to find the center of the arc, then compare the point-to-center distance to the arc radius
[10:38:52] <seb_kuzminsky> bbl, changing busses
[10:38:54] <cradek> I wonder what the tolerance even means in a x-b-w move
[10:39:16] <cradek> brb
[10:50:41] <seb_kuzminsky> i dont know what tolerance means for rotary axes
[10:51:51] <seb_kuzminsky> for an x-b-w line, i think you can treat the xw component just like you'd treat an xy line
[10:54:49] <skunkworks> cradek: http://imagebin.org/309541
[10:56:57] <archivist> I think tolerance is move dependent
[11:00:22] <archivist> some may want to put different tolerances on various axes due to the differing effect of each axis on the built up tolerance
[11:00:30] <cradek> skunkworks: so it didn't help?
[11:01:34] <cradek> skunkworks: the way your sim shows the program is different from mine. Do you have only A rotation showing? I'm using the sillily-named sim/axis/axis_9axis
[11:02:43] <skunkworks> I think I changed geometry
[11:03:10] <skunkworks> GEOMETRY = AXYZBCUVW
[11:06:06] <cradek> GEOMETRY = XYZABCUVW
[11:06:55] <skunkworks> better http://imagebin.org/309544
[11:06:58] <skunkworks> ?
[11:08:09] <cradek> matter of preference, but I like it better that way (A is not special)
[11:09:09] <skunkworks> it is kinda cool though. the only thing that would be neater'er would be to rotate the preview instead of the cone...
[11:09:45] <cradek> smop
[11:09:49] <skunkworks> heh
[11:10:09] <cradek> I think it would be really disorienting
[11:11:03] <skunkworks> but more like the actual machine. (well certain machines) where the rotory axis sitting on the table. the 'part' would be rotating as it is on the actual machine.
[11:11:20] <cradek> yes that's true
[11:11:32] <cradek> so the xyz arrows would spin around
[11:11:43] <skunkworks> exactly
[11:11:55] <cradek> a bc machine with c on the table is like that, too
[11:12:07] <cradek> you'd want the cone to tilt for b, and the arrows to spin for c
[11:12:14] <skunkworks> exactly
[11:12:24] <skunkworks> smop
[11:12:33] <cradek> that's the spirit
[11:21:17] <skunkworks> and no - the max velocity isn't reached on v and w
[11:21:46] <skunkworks> would it be easy to increase the segment lengths?
[11:31:44] <cradek> skunkworks__: just change the code! send me whatever you end up with and I'll commit it.
[11:57:14] <skunkworks_> logger[psha]:
[11:57:14] <logger[psha]> skunkworks_: Log stored at http://psha.org.ru/irc/%23linuxcnc-devel/2014-05-07.html
[12:30:40] <seb_kuzminsky> i'm working with a guy named Jaroslav Tsekov to fix a bug he found in the Delta VFD-B driver, he contacted me with a great bug report, including a patch
[12:30:51] * seb_kuzminsky has a happy
[12:41:16] <skunkworks_> awesome!
[12:44:59] <alex_joni> who is?
[12:47:54] <seb_kuzminsky> who is Yaroslav? i have no idea
[12:47:57] <seb_kuzminsky> some dude on the internet?
[12:57:57] <alex_joni> you scared him
[13:23:07] <cradek> a bug report and patch - yayyy
[13:24:25] <skunkworks__> https://www.youtube.com/watch?v=y6Sxv-sUYtM
[13:27:40] <cradek> I didn't expect to like that, but I did as it went on
[13:28:05] <cradek> he's not really even singing that ... oh none of them are, that's the point
[13:31:34] <cradek> https://www.youtube.com/watch?v=BqNHW9Yr4Kg
[13:31:41] <cradek> more my style
[13:38:28] <skunkworks__> :)
[13:38:40] <skunkworks__> you know banjos are back in...
[13:41:09] <cradek> well they're really singing it... I think they probably spent less on production costs for this video than yours.
[13:43:57] <skunkworks__> http://youtu.be/hicQqueoEIQ
[13:46:37] <cradek> I've never seen someone flat-pick a banjo...
[13:55:19] <skunkworks__> https://www.youtube.com/watch?v=lnaJkMxxSig
[13:55:45] <skunkworks__> oh - for some reason I thought they used a banjo in that song
[13:58:19] <cradek> is this radio station local to you?
[14:09:55] <skunkworks__> minniapolis..
[14:10:29] <skunkworks__> so 2.5 hours away. We stream it. (it is part of mn public radio)
[14:53:07] <seb_kuzminsky> does anyone have a 7i84?
[14:53:18] <seb_kuzminsky> wait, is there even a 7i84? maybe the guy meant 7i64...
[14:53:59] <seb_kuzminsky> there is a 7i84... hmm..
[16:06:09] <Robert302> hello cradek! I've set up a public git for my project. The url is: http://c-416.ahl.uni-linz.ac.at:8080/gitweb or http://c-416.ahl.uni-linz.ac.at:8080/linuxcnc/! I've checked in a commit named "Data Logger and Comedi Driver" the things are not finished until now but they are already working. I' have to add a view more comments and i am not sure if i do my logging right in the logger.c file. Until now i'm using rtapi_print_msg() but this
[16:07:38] <cradek> great, looking now
[16:08:00] <cradek> your message was cut off after "rtapi_print_msg() but this" (irc stupidly has a length limitation)
[16:09:35] <cradek> ... I'm trying to understand how comedi and rtai fit together, and why you had to change rtapi.conf
[16:09:39] <Robert302> that's bad. Now i am using rtapi_print_msg() in my userspace part of the logger if there happens something. I'm not shure if this is right
[16:10:19] <Robert302> the problem is that the comedi project already inserts rtai_hal
[16:10:55] <Robert302> so if i started the script/realtime start an error happen
[16:11:18] <Robert302> it was only a fast fix for me maybe there is another way to do it
[16:11:27] <cradek> do you have special hardware that has comedi drivers?
[16:11:51] <cradek> I'm trying to understand the big picture here
[16:13:13] <Robert302> the http://www.comedi.org/ project gives you a defined interface to communicate whit PCI cards from different manufactures
[16:15:13] <cradek> so comedi runs on top of rtai?
[16:16:02] <Robert302> in my case i have an National Instruments card. The problem is that the amount of analog and digital in an outputs different depending on the type of card. As i told you this is now only working for one type of card but i have two different types to test it
[16:16:10] <Robert302> yes comedi is using rtai
[16:16:48] <Robert302> i'm running my base thread now with 10 KHz and this is working really nice
[16:17:20] <cradek> so am I right that hal_comedidri creates hal pins, and connects them to comedi-supported hardware?
[16:17:45] <Robert302> so i get an analog value ever 0,0001 second to my logger and with this measurements i'm drawing pictures of magnetic fields in matlab
[16:18:01] <Robert302> yes this is right
[16:18:18] <cradek> neat
[16:18:57] <cradek> your hardware has analog inputs, and you go through the card's comedi driver to get these values at the hal pin comedidri.%d.ana-%02d-in
[16:20:00] <cradek> how do you tell what inputs/outputs are available from the comedi driver?
[16:20:01] <Robert302> yes there i get an uint value and with the pin comedidri.%d.ana-%02d-in-range i could select a meashurment scale of the card
[16:21:18] <Robert302> the comedi projects gives you a method comedi_get_subdevice_type and some other
[16:21:35] <Robert302> with them it would be possible to check out what kind of channel you card has
[16:21:43] <Robert302> but this is not implemented until now+
[16:21:50] <cradek> I understand, you have not done that yet
[16:21:55] <Robert302> yes
[16:22:18] <Robert302> this is now only for one type of card the National Instruments PCI-6014
[16:22:29] <cradek> is it true that the logger is a separate thing that does not depend on comedi etc?
[16:22:44] <Robert302> yes this thing is separate
[16:23:07] <Robert302> my idea was to make a clean thing and with the power of hal it is possible to do this
[16:23:29] <cradek> both pieces look useful to me
[16:23:57] <cradek> looks like hal_comedidri will need to have a configure option to control whether it is built, because of #include <linux/comedilib.h> I can see it won't build on systems without comedi
[16:24:14] <cradek> looks like the logger can always be built
[16:24:53] <cradek> maybe you could split the logger into its own commit, and then make a second commit with hal_comedidri and the necessary configure changes
[16:24:54] <Robert302> this is right to build the comedi module the driver has to be installed and symlinked right.
[16:25:22] <cradek> looks like the scope_rt.h change is just a mistaken change that can be removed
[16:25:30] <seb_kuzminsky> Robert302: do you know about halsampler? i use it for logging hal pin values sometimes
[16:25:38] <Robert302> oh yes it was a reference for me
[16:25:44] <seb_kuzminsky> cool
[16:26:18] <cradek> also please make sure each of your new files has a full license statement
[16:26:38] <cradek> haha oops: * Description: hal_speaker.c
[16:26:45] <Robert302> no i din't know i look around in the code and i found emcrsh.cc
[16:27:12] <cradek> I have to leave for now
[16:27:24] <cradek> Robert302: good to meet you, and I hope my suggestions help
[16:28:17] <Robert302> thank you for your time it's my first time to work with an community project so i am happy to get some feedback
[16:29:40] <Robert302> @seb_kuzminsky is it possible with the halsampler to log to a buffer and read it from userspace without stop logging?
[16:34:16] <seb_kuzminsky> yep
[16:34:41] <seb_kuzminsky> there's a realtime component that samples into a buffer (user configurable size), and a userspace program that reads the buffer
[16:35:03] <seb_kuzminsky> look at the sampler and halsampler manpages
[16:35:55] <seb_kuzminsky> for an example, look at tests/edge/rising
[16:37:24] <Robert302> that's bad for me =) ... thanks i have to take a look at it.
[16:38:09] <seb_kuzminsky> what's bad?
[16:40:28] <Robert302> just a joke ... i mean i spent two days to write the logger_rt.c module
[16:41:22] <Robert302> if i would have known, i would have looked first to the existing component
[16:52:09] <seb_kuzminsky> oh, i see
[16:52:27] <seb_kuzminsky> "a couple of weeks in the laboratory can often save you several hours in the library"
[16:53:27] <Robert302> do i unserstand right, with the streamer it is possible to send data from a file to a hal pin.
[16:54:57] <seb_kuzminsky> exactly
[16:55:05] <seb_kuzminsky> streamer moves data from userspace to hal
[16:55:14] <seb_kuzminsky> sampler moves data from hal to userspace
[20:55:02] <cradek> :-(
[21:40:57] <skunkworks_> logger[psha]:
[21:40:57] <logger[psha]> skunkworks_: Log stored at http://psha.org.ru/irc/%23linuxcnc-devel/2014-05-08.html
[22:12:24] <skunkworks_> cradek: why the sad face?