Back
[01:43:50] <ries_> ries_ is now known as ries
[03:02:19] <jepler> micges: there's something weird about the message, but this time difference *is* significant: 3480642 vs 2369620 is 30% difference
[03:05:50] <jepler> as well, 2934415 is more than 1.2*2369620
[03:08:09] <jepler> so the question is: why didn't the code fire when it encountered the much bigger difference between 3480642 and prior history such as 2369620?
[03:09:11] <jepler> if this was at the very start of a run, I suppose the big figure could have been during priming
[07:09:41] <alex_joni> jepler: I think the code doesn't fire for the first 5 runs
[07:10:09] <alex_joni> so only after it gathers enough data (and the error was in the second run) it fires on run #6 by checking the mean of first 5 against current
[14:01:35] <jepler> alex_joni: it's not checking the mean of 5, it's checking any of the 5
[14:01:59] <jepler> alex_joni: but you're right about the start of the run -- it's based on the variable called 'priming'.
[14:50:33] <CIA-2> EMC: 03jepler 07v2.4_branch * rdc12848308b5 10/src/hal/components/estop_latch.comp: estop_latch: make watchdog behavior match documentation
[15:53:13] <alex_joni> jepler: err, right, any of them
[17:46:55] <micges> jepler: this message wasn't at start, it was after minimize and maximize Axis
[18:52:25] <CIA-2> EMC: 03jepler 07v2.4_branch * re0fbe2669c1b 10/ (VERSION debian/changelog): release 2.4.6
[18:58:25] <cradek> yay!
[20:31:11] <skunkworks> Nice Oerik!
[20:31:20] <skunkworks> heh - Nice Work1
[20:31:25] <skunkworks> heh - Nice Work!
[20:31:40] <skunkworks> being curled up in a couch sure makes typing hard.
[20:34:13] <psha> i've some minor problem with axis and external apps embeded in it
[20:35:25] <psha> problem is if program is HAL component and need some pin wiring it's not possible to determinesay reliably when it's ready and run HAL file with 'net' commands
[20:35:49] <psha> one possible way is to add some flags to programs (gladevcp, camera) for HAL files to execute after they are ready
[20:36:16] <cradek> halcmd has a way to wait until a subprocess calls hal_ready()
[20:36:28] <cradek> (I don't know the details...)
[20:37:23] <psha> yes, but consider setup with say gladevcp panel and camera window
[20:37:27] <psha> both are hal comps
[20:37:52] <psha> they are started and i may wait for them (individually) to settle and run hal file
[20:38:21] <psha> but if they signal between them is needed?
[20:38:41] <psha> only way i see is to first create signal for them and then connect pins separately
[20:38:52] <psha> hm, maybe that's not bad
[20:40:37] <psha> i was thinking if it's possible to offload component waiting on axis but config file will be bloated with variables then...
[21:39:52] <micges> jthornton: in 2.4 there are wrong description about g87 and g88 as unimplemented, they are working
[21:40:30] <cradek> really? I'm shocked to hear that
[21:41:44] <micges> why? are they work properly?
[21:41:57] <cradek> that's what I'm asking
[21:42:04] <cradek> I have not tried them but I figured they did not work
[21:42:52] <micges> oh
[21:43:18] <micges> I must recheck
[21:43:39] <jthornton> hi micges
[21:43:44] <micges> hi
[21:44:07] <jthornton> let me know :)
[21:44:17] <micges> ok
[22:04:07] <micges> cradek: g87 works according to nist docs
[22:06:22] <cradek> I don't see how that's possible, since we don't have spindle orient
[22:09:04] <cradek> other than that, seems like it could work
[22:09:26] <micges> yes, exactly
[22:20:11] <jthornton> g87 would need spindle orient to be useful
[22:20:21] <cradek> yes
[22:20:49] <jthornton> spindle orient would also be useful for tool changers :)
[22:20:51] <cradek> also it would have to wait for at-speed at the right times - it might already do that
[22:21:24] <cradek> jthornton: my machine orients for tool change - also I have a toggle switch for orient/lock which I use mostly to close albrecht chucks
[22:22:04] <andypugh> built-in spindle orient would be rather nice. I guess it would need its own PID parameters at the very least.
[22:22:34] <cradek> machines orient in many different ways
[22:22:38] <cradek> pid is no use for mine
[22:23:11] <skunkworks> or mine.
[22:23:11] <jthornton> I think mine uses the index from the encoder to orient the spindle
[22:23:14] <cradek> stop spindle - turn on orient pin - jog spindle - when orient pin pops into place, turn off jog
[22:23:50] <cradek> seems like another hal loopback for orient is what we'd want
[22:24:01] <jthornton> so you have a physical stop to orient to?
[22:24:01] <skunkworks> I would think you could just have 2 pins - in and out.
[22:24:03] <skunkworks> yes
[22:24:14] <andypugh> I was thinking that, rather like the toolchange
[22:24:18] <cradek> jthornton: yes it's a hard mechanical lock - very very nice
[22:24:41] <andypugh> Well, you might want the orient-angle as an output too, in the same manner as toolnumber.
[22:24:49] <skunkworks> yes - like the tool change.
[22:25:07] <cradek> andypugh: true you might want different angles (but I'm not sure what for)
[22:25:32] <skunkworks> I think some machines use it as an indexer.
[22:25:35] <cradek> broaching :-)
[22:32:06] <andypugh> axis.py is interpreted, yes?
[22:32:26] <andypugh> ie changes work without compilation?
[22:32:28] <cradek> python is always interpreted
[22:33:06] <cradek> I think the emc makefile copies it from one place to another for you, and renames it, and extracts strings for translation
[22:33:19] <cradek> so depending on exactly what you're asking the answer might change
[22:33:31] <andypugh> Perhaps I should step back a pace, and ask the real question, which is from the forum. Axis defaults to view_p and someobody wants to startup in Z
[22:33:53] <cradek> I bet there's something you could put in .axisrc to do that for you
[22:34:12] <cradek> better would be for it to remember across runs (like it remembers a lot of other things)
[22:34:25] <cradek> it could write that into .axis_preferences or whatever it's called
[22:34:43] <andypugh> It just occurred to me that he might have a lathe...
[22:34:58] <cradek> lathe does not have multiple views
[22:35:13] <andypugh> LATHE = true might be what he needs. Does that do anything else other than fix the view?
[22:35:36] <cradek> yes, it gives you dia/rad dro for X
[22:35:47] <cradek> and probably a lot of other little things - I don't remember
[22:37:02] <andypugh> Tool orientation and offsets, I assume
[22:37:25] <cradek> yeah it gives you the neat tool tip view
[22:37:28] <cradek> so yeah, lots
[22:39:42] <andypugh> If you put "Basic Config" into the search box on the left, you get the page you want, but for the 2.2 version.
[22:40:06] <andypugh> Is there any real point in keeping the very old version docs "live"
[22:40:59] <cradek> bleh
[22:41:03] <cradek> I dunno how to fix that
[22:42:06] <andypugh> I only noticed as I was sure the word "lathe" should be on the page somwhere.
[22:42:22] <cradek> how do you spell (mapcar '* a b) in python?
[22:43:50] <andypugh> SImilarly, someone who emailed me today was struggling with the instructions on debounce here:
http://linuxcnc.org/docs/html/hal_rtcomps.html
[22:44:28] <andypugh> Which seems to assume that you will be loading the realtime components from the command line?
[22:45:34] <cradek> early hal docs were written to be not specific to using hal with emc
[22:46:01] <andypugh> I guess that is fair enough.
[22:46:27] <andypugh> To be honest I don't have any solutions, but the project seems over-documented in some ways.
[22:46:29] <cradek> it's never clear what is best to do with old docs (deleting them vs preserving old links to them, etc)
[22:47:10] <cradek> it's true nobody likes the state of our docs - but sadly they each have a different complaint
[22:47:22] <cradek> I heard a lot of this at emc fest
[22:47:52] <cradek> one guy insisted all the documentation sucked and it should be replaced with videos
[22:48:37] <cradek> another guy said videos were for people who can't read and write, and it's a waste of his time to watch someone's talking head on a screen
[22:48:44] <andypugh> How difficult would it be to run a macro that put a header at the top of all the HTML files which have not changed for over a year with "Warning, this document might be out of date, consider starting at this page:" and a link to the main docs entry page?
[22:48:55] <cradek> (paraphrasing on that last one :-)
[22:49:27] <andypugh> Were you more or less polite in the original?
[22:49:33] <cradek> I don't know the answer to that question
[22:49:35] <cradek> haha
[22:49:41] <jthornton> seems like everyone has an opinion on the docs lol
[22:49:46] <cradek> you think you recognize the second guy??
[22:49:54] <cradek> jthornton: ain't that the truth
[22:50:47] <andypugh> jthornton: My main opinion is that I think you do a better job than can reasonably be expected.
[22:51:14] <jthornton> cradek: I think I might recognize the second guy but he hides from the camera I think...
[22:51:25] <jthornton> andypugh: thanks
[22:52:33] <jthornton> my main drive on working on the docs is if I can't understand it then there is a lot of other people who can't...
[22:53:02] <jthornton> YEA! the Cycle timer is done and working :)
[22:53:04] <cradek> jthornton: I think the stuff you've touched recently is always pretty good - but we have so much that's just old crap
[22:53:35] <cradek> jthornton: as insiders, we know where the gems are - some of the lyx stuff (not all!) - some pages on the wiki (not all!) - etc
[22:54:02] <cradek> maybe we ought to just outright delete anything that's crap
[22:54:14] <jthornton> yes, knowing where to look is 3/4 of the task
[22:54:18] <andypugh> I am growing fonder of the idea of a nice big banner at the top of files older than a year pointing out how old they are.
[22:54:20] <cradek> (but who decides that? somebody wrote each of those pieces of crap)
[22:54:45] <jthornton> and at the time they thought they were doing the right thing
[22:54:56] <cradek> YES - and they may have been, even
[22:54:58] <andypugh> At the time, they were.
[22:55:00] <cradek> (may)
[22:55:02] <cradek> haha
[22:55:16] <jthornton> an age on a document header might be a good thing
[22:55:47] <cradek> but age alone doesn't distinguish gem vs turd
[22:55:55] <jthornton> This Document is 1023 days since the last update!
[22:56:06] <jthornton> no, but it might make you question it
[22:56:34] <andypugh> The issue that I am considering is that Google and the on-site search throw up 2.1 docs just as cheerfully as 2.4 docs.
[22:56:54] <mshaver> Would O'Reilly publish a book? That might pay for the work to consolidate all this stuff...
[22:57:01] <andypugh> And they even look exactly the same
[22:57:05] <jthornton> I'm still keen on splitting the G,M, and O codes out of the user manual and leave it for user interfaces...
[22:58:03] <andypugh> If I put a break in an if in a switch, it drops me out of the if, not the switch?
[22:59:02] <micges> switch
[22:59:48] <andypugh> I had a "return". That was very wrong. But "break" is working even less well.
[23:01:00] <cradek> aha: map(lambda x,y: x*y, a, b)
[23:03:36] <cradek> andypugh: I feel your pain
[23:05:47] <andypugh> Actually, it is working perfectly now. I possibly left out the all-important "make" step....
[23:06:33] <jthornton> andypugh: your making some of my mistakes
[23:06:41] <andypugh> The alternative is that the rtapi_prints I put in to see what was really happening are functionally critical, which I hope is not true.
[23:07:08] <CIA-2> EMC: 03jthornton 07master * r74df79ee5e31 10/src/hal/components/time.comp: use period to simplify the connections
[23:07:25] <andypugh> jthornton: I started programming in 1980, I think you will find these are _my_ mistakes ;-)
[23:08:01] <jthornton> andypugh: thanks for the tip on using period for the time comp
[23:08:13] <jthornton> it worked out rather nice
[23:08:27] <micges> andypugh: err how old are you?
[23:08:29] <andypugh> Is it mentioned in the comp docs? There is lots you can do in comp that is not really covered.
[23:08:38] <andypugh> I am 43.
[23:08:54] <jthornton> I'm not sure if it is in the comp section of the HAL manual but I'll check
[23:09:02] <jthornton> you are a young man then
[23:09:14] <micges> heh I'm 26
[23:09:33] <andypugh> I sold my first programme (as we spelt it them) at 14
[23:09:42] <jthornton> I pretended to be 7 for the last few days lol
[23:10:00] <jthornton> wore me out
[23:10:05] <andypugh> Then gave up on the basis that computing was a passing fad :-)
[23:11:01] <andypugh> MattyMatt was properly famous as a kid-programmer, you know. National newspapers, magazines...
[23:11:03] <jthornton> andypugh: do you know if there are any other variables passed to a comp?
[23:11:43] <andypugh> The way to find out it so look at the compiled C code, any variable in there is usable.
[23:13:36] <andypugh> The only other one I know of offhand is extra_arg which only works in EXTRA_SETUP and tells the comp which instance it is.
[23:13:55] <andypugh> And I suspect that that is too confusing a concept for most.
[23:14:19] <jthornton> it is too confusing for me lol
[23:23:21] <CIA-2> EMC: 03jthornton 07v2.4_branch * r4bbdc38db7e2 10/docs/src/hal/comp.lyx: add info on the period variable
[23:23:22] <CIA-2> EMC: 03jthornton 07v2.4_branch * r8750a3b827c5 10/docs/src/gcode/main.lyx: add info on O parameters
[23:24:48] <jepler> ugh, my dsl is grumpy today
[23:27:11] <andypugh> jthornton: the time docs have put all the hal code on one line in my browser.
[23:27:11] <jthornton> you should try my tin can and string setup for a while :) that is fun
[23:27:35] <jthornton> andypugh: ok
[23:28:24] <jthornton> yea, me too
[23:28:55] <jepler> jthornton: yeah, unfortunately I'm trying to copy the debs around for this new release
[23:29:45] <jthornton> ouch
[23:29:50] <cradek> jthornton: I think buildbot is complaining about something you did:
http://emc2-buildbot.colorado.edu/buildbot/builders/lucid-i386-sim/builds/235/steps/compile/logs/stdio
[23:30:47] <jthornton> it complains so much...
[23:31:26] <jepler> the "u32" type is available in rt and not in sim. Use __u32 when you want to refer to the non-volatile type that stores the same range of values as hal_u32_t.
[23:31:58] <cradek> huh, glad jepler was here.
[23:32:16] <jthornton> for the global?
[23:32:29] <jthornton> no...
[23:33:05] <jepler> + u32 totalseconds;
[23:33:06] <jthornton> in the function? u32 totalseconds?
[23:33:08] <jthornton> ok
[23:33:33] <jthornton> me too
[23:33:34] <andypugh> jepler: Is that generally true? ie should I swap all my u32 declarations to hal_u32_t?
[23:33:40] <jepler> I can easily compile-check it here
[23:33:49] <jthornton> ok
[23:34:04] <jepler> andypugh: in drivers it doesn't matter since they aren't built on sim
[23:34:39] <andypugh> OK, it did occur to me that anyone trying to use hostmot2 drivers in sim has other problems.
[23:34:49] <andypugh> But how about in comps?
[23:35:40] <jthornton> * jthornton wonders what thought process led me to use u32 for hours, minutes, and seconds?
[23:35:58] <jthornton> they should be int I think
[23:36:09] <jepler> that would have been fine too
[23:36:11] <andypugh> I only seem to have used int, float and char. But I am now recalling something about float being less good than double in the HAL context?
[23:36:54] <jepler> andypugh: never use "float". Use "double". "hal_float_t" is actually a double now (but we didn't change the name so that old code would continue working unchanged)
[23:37:04] <andypugh> hours minutes and seconds are HAL pins, do they exist as int?
[23:37:23] <jthornton> ahh, it was the lack of an int number display in pyvcp
[23:38:05] <jthornton> andypugh: on my time comp?
[23:38:20] <andypugh> Yes
[23:38:31] <jthornton> no, at this moment they are u32
[23:38:44] <jthornton> as pyvcp didn't have an int number display
[23:39:02] <andypugh> My question was whether they are u32 because they have to be, as hal pins always are that or float or bit.
[23:39:02] <jthornton> leftover time bbib
[23:39:37] <jthornton> only because there is no int number display in pyvcp
[23:39:59] <jepler> there's no pin or paramter type "int", there's only hal_u32_t and hal_s32_t, which are sometimes called u32 and s32 for shorthand
[23:40:02] <jthornton> and you would have to convert them to something that pyvcp has to use them
[23:40:21] <jthornton> oh...
[23:40:54] <andypugh> so u32 was the correct choice..
[23:43:31] <jthornton> TYPE One of the HAL types: bit, signed, unsigned, or float. The old names s32 and u32 may
[23:43:32] <jthornton> also be used, but signed and unsigned are preferred.
[23:43:45] <jthornton> I finally found that in the HAL manual
[23:44:32] <andypugh> It's on the "Comp" page too. As is the varible "fperiod" which I had completely missed when I told you to use "period"
[23:44:57] <andypugh> fperiod is floating-point seconds, and would have been more convenient.
[23:45:12] <jthornton> yes
[23:45:53] <jthornton> so c types like int can be used in the main body but not as pins I assume now
[23:46:29] <andypugh> Incidentally the trick to getting single-spaced code on seperate lines in groff is to precede each line with a space.
[23:48:26] <andypugh> (But I have no idea how to get it to show tabs correctly)
[23:54:12] <mshaver> andypugh: do you have any hal files that show how to operate the 8i20?
[23:54:54] <jepler> jepler has changed the topic to: EMC2 development --
http://linuxcnc.org/ | Latest release: EMC 2.4.6
[23:54:58] <andypugh> Nothing very tidy
[23:55:01] <jepler> OK, I think it's done!
[23:55:03] <jepler> bbl guys
[23:55:07] <mshaver> For example, creating the "angle" from the encoder count?
[23:55:33] <mshaver> tidy is not that important right now :)
[23:55:35] <andypugh> Ah, yes, well, you need bldc.comp
[23:55:47] <mshaver> is that in master?
[23:55:54] <andypugh> No.
[23:56:01] <mshaver> 2.4
[23:56:05] <mshaver> ?
[23:56:08] <andypugh> Neither
[23:56:40] <andypugh> I sent it to the dev list for comments, and I am actually sulking that it was totally ignored.
[23:56:45] <mshaver> I'm sort of used up on guesses!
[23:57:02] <mshaver> Ah! Wait, I'll look!
[23:57:27] <andypugh> Let me pastebin the latest
[23:58:07] <andypugh> http://www.pastebin.ca/2003351
[23:58:44] <andypugh> Though I don't think I have changed anything other than spelling and changed float to double.