Back
[00:03:02] <SWPadnos> yeah. even I could do it :)
[00:05:44] <BigJohnT> SWPadnos: you here
[00:05:53] <SWPadnos> it seems so
[00:06:08] <SWPadnos> should I be here with a Linux machine that I can observe gs2 HAL pins with?
[00:06:18] <BigJohnT> got time to give me a couple of hints
[00:06:32] <SWPadnos> ye. their usefulness is not guaranteed though
[00:06:50] <BigJohnT> guarantees not needed :)
[00:07:09] <BigJohnT> what needs to get connected to what to make it work in hal?
[00:07:32] <SWPadnos> you need to set the no-load speed and the base frequency
[00:07:37] <SWPadnos> (should be parameters)
[00:07:42] <BigJohnT> I have the comms set in the drive to the defaults of the component
[00:07:44] <SWPadnos> you should also set a max frequency
[00:08:00] <SWPadnos> ok, you should be able to change those with command line parameters
[00:08:09] <BigJohnT> in the drive?
[00:08:16] <SWPadnos> no, the driver :)
[00:08:21] <SWPadnos> the HAL component
[00:08:29] <BigJohnT> ok looking at the pins
[00:08:52] <BigJohnT> but think that they are params
[00:09:02] <SWPadnos> you can't change the comm parameters once the driver is loaded, so hopefully you're not looking at that
[00:09:28] <BigJohnT> I'm just looking at the hal configuration screen at the moment
[00:09:53] <SWPadnos> ok. I'm not, so you may have to refresh my memory :)
[00:10:45] <BigJohnT> is scale_frequency the base freq?
[00:14:16] <SWPadnos> one sec. looking at the source
[00:14:22] <BigJohnT> ok
[00:14:58] <SWPadnos> no, that's feedback from the drive, I think it's the current frequency output
[00:15:24] <SWPadnos> motor-HZ and motor-RPM are the two you have to se
[00:15:26] <SWPadnos> t
[00:15:44] <SWPadnos> probably 60 for motor-HZ, and whatever the nameplate says is the no-load speed for RPM
[00:16:02] <SWPadnos> (actually, the nameplate will tell you the frequency as well, it's just likely to be 60 here in the US)
[00:16:16] <BigJohnT> ok, now how do know what the comm port is?
[00:16:30] <SWPadnos> it's ttyS0 unless you used something else
[00:17:01] <SWPadnos> I did consider (at the start of this conversation) adding status parameters so you can see what it's using in HAL
[00:17:07] <BigJohnT> not that I know of LOL
[00:17:24] <SWPadnos> but since there's no way to put a string on a HAL pin, it's not going to be all that useful :)
[00:18:29] <BigJohnT> looks like I have two serial ports
[00:18:31] <SWPadnos> you could run gs2_vfd -h or --help to get a list of the command line parameters
[00:18:48] <BigJohnT> I have them in the manual :)
[00:18:49] <SWPadnos> the number of ports in /dev may or may not be related to the number of physical ports
[00:18:57] <SWPadnos> yes, I know you put that part in there :)
[00:19:46] <BigJohnT> do you think hot plugging the communications cable in will cause a problem?
[00:20:15] <SWPadnos> no. it will cause an increase in the number of serial errors (reported on the errorcount pin)
[00:20:29] <SWPadnos> in fact, you can see if the comm parameters are set u pright by looking at that
[00:20:39] <SWPadnos> set up right
[00:20:45] <BigJohnT> the drive is set for RS485 so I need to switch that first and stir the taco meat
[00:21:03] <BigJohnT> be back in a second or three
[00:21:04] <SWPadnos> heh
[00:21:17] <SWPadnos> I may need to go make the TV show my wife pretty pictures :)
[00:21:37] <SWPadnos> and who knows, maybe I'll watch a little too. so bbl (or sooner) :)
[00:22:23] <BigJohnT> ok
[00:23:01] <BigJohnT> smells like dinner is ready here...
[00:38:48] <jmkasunich> SWPadnos: how did the lathe move go?
[00:51:45] <BigJohnT> SWPadnos: the fwd pin works but I get a comm error about an illegal data value...
[00:52:42] <BigJohnT> I'll look at it a bit later
[01:11:56] <CIA-48> EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/ (stepconf.glade stepconf.py):
[01:11:56] <CIA-48> EMC: Add an advanced page to stepconf to help with configuring classicadder, Hal ui,
[01:11:56] <CIA-48> EMC: and pyvcp still need to have temp CL file copied to user config on finish and
[01:11:56] <CIA-48> EMC: add code to connect HAL of sample ladders- small step for emc-kind giant leap
[01:11:57] <CIA-48> EMC: for one man
[01:33:06] <SWPadnos> jmkasunich, the lathe didn't move today. by the time our guests left and I made room in the garage, the temperature had gone down to 15 or so
[01:33:13] <SWPadnos> with 25 MPH wind gusts
[01:33:32] <SWPadnos> so it'll sit on the trailer for a couple more days
[01:55:32] <seb_kuzminsky> jepler: what splitting of the debian packages do you think we want for 2.3?
[01:55:45] <SWPadnos> docs, drivers, core ...
[01:55:57] <SWPadnos> (yes, I know I'm not jepler :) )
[01:56:04] <seb_kuzminsky> when would someone install core but not drivers?
[01:56:24] <SWPadnos> "extra drivers" - like firmwares and stuff
[01:56:36] <SWPadnos> I don't know really - just putting that split out there
[01:56:49] <seb_kuzminsky> emc2 vs docs i can see, no problem
[01:56:51] <SWPadnos> and maybe a larger set of sampler configs as well - dunno
[01:56:56] <seb_kuzminsky> hmm
[01:57:43] <SWPadnos> there's also been some talk about a minimal install, maybe even something that doesn't depend on X (text only UIs, HAL ...)
[01:58:11] <SWPadnos> so core might be the base needed for a HAL/EMC system with no UI, and then you add the UI part, which depends on X
[01:58:18] <SWPadnos> if you need it
[02:03:13] <jepler> seb_kuzminsky: well, my big item is a "here ya go" for people who complain that emc has lots of deps -- emc2 + keystick + nothing useful (but fewer external deps)
[02:03:22] <jepler> but that really doesn't help any real actual users, just whiny people
[02:03:29] <SWPadnos> whine whine
[02:16:21] <CIA-48> EMC: 03cmorley 07TRUNK * 10emc2/configs/common/configurable_options/ladder/ (blank.clp estop.clp serialmodbus.clp): add stepconf selectable ladder programs
[02:21:43] <CIA-48> EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: Changes to have advance page's ladder selection seek from the newly commit directory configurable_option/ladder
[02:53:38] <seb_kuzminsky> mmm whiners
[02:58:24] <seb_kuzminsky> speaking of which, the recent addition of configs/common/configurable_options broke the build
[02:58:52] <seb_kuzminsky> it's a directory, and the install invocation balks
[03:00:00] <seb_kuzminsky> farmer
[03:00:03] <seb_kuzminsky> oof
[03:03:12] <seb_kuzminsky> i just ran keystick for the first time - lol
[03:03:30] <seb_kuzminsky> yeah, 1982 called, they want their user interface back
[03:08:04] <SWPadnos> don't laugh. it could (don't know if it's still current) do most anything you need - jog, start/stop/pause/run, set overrides, etc
[03:08:20] <SWPadnos> it doesn't have preview, but that's not really necessary
[03:08:36] <SWPadnos> (it's pretty, and it's useful, but not necessary)
[03:11:54] <jepler> the biggest problem that comes to mind is the impossibility of correctly handing continuous jogs with a tty interface
[03:12:04] <jepler> (you have to guess at when a "no repeat" non-event means the key was released)
[03:12:17] <SWPadnos> there are key release codes
[03:12:27] <SWPadnos> repeat is a software function
[03:13:36] <jepler> no, it's a function of the teletype. all the server receives is a bunch of repeated ASCII codes
[03:14:00] <jepler> curses circa 1993 didn't have a way to detect "key up"; I don't know that the situation has changed in 2009.
[03:14:22] <SWPadnos> strange. I know that there were key release codes at some point
[03:14:57] <jepler> on pc keyboards sure there are release keycodes if you switch into the right raw mode
[03:15:02] <jepler> but curses isn't for pcs, it's for glass teletypes
[03:15:07] <SWPadnos> true
[03:17:09] <seb_kuzminsky> of all the dirs in configs/, only common has subdirs
[03:17:20] <seb_kuzminsky> those subdirs were just added by chester aka cmorley
[03:17:26] <seb_kuzminsky> and they break the .deb build
[03:17:54] <seb_kuzminsky> i'm not sure what the right way to fix it is
[03:18:18] <SWPadnos> I don't think there's a design reason for forbidding subdirectories in the configs dir
[03:18:19] <jepler> we'll want them copied to /etc/emc2/sample-configs
[03:18:29] <jepler> SWPadnos wants subdirectories for another reason iirc
[03:18:31] <SWPadnos> so copying them is the correct answer, I think
[03:18:33] <SWPadnos> yep
[03:18:35] <jepler> but he also has to patch pickconfig
[03:18:40] <SWPadnos> though I haven't gotten it all to work yet :)
[03:18:47] <seb_kuzminsky> fix the INSTALL_CONFIG function in our src/Makefile to handle subdirs, ok will do
[03:19:10] <seb_kuzminsky> only the "common" config has subdirs, and i dont think it's a real config
[03:19:21] <seb_kuzminsky> more like a library of things useful to build real configs out of
[03:19:25] <SWPadnos> right
[03:20:20] <SWPadnos> I want to see them because I think it would be better to have e.g. mesa/7i43 and mesa/5i20 subdirs, instead of dumping all the files into one dir or making serparate top-level dirs for each config
[03:20:47] <seb_kuzminsky> SWPadnos: that *would* be nice :-)
[03:20:51] <SWPadnos> yep
[03:21:02] <SWPadnos> o I have to figure out how the hell to get pickconfig to do it right :)
[03:21:04] <SWPadnos> so
[03:21:31] <SWPadnos> jepler even gave me code to make a tree, but I still haven't figured out how to get to the end product
[03:22:12] <jepler> I hope you know where that code is, because I have no idea
[03:22:25] <SWPadnos> I have a copy on my laptop, I think
[03:23:52] <seb_kuzminsky> is there a reason why the CONFIGS variable in the Makefile lists the configs explicitly, instead of doing wildcard expansion in configs/?
[03:24:21] <SWPadnos> you mean a good reason, or any old reason? :)
[03:24:39] <seb_kuzminsky> ok i'll fix it ;-)
[03:25:40] <seb_kuzminsky> yuck, CVS puts CVS directories in every directory it manager
[03:25:54] <cradek> and now you know why
[03:25:56] <jepler> seb_kuzminsky: yep, that's a feature
[03:26:03] <jepler> $(filter-out %/CVS, whatevah)
[03:26:14] <jepler> there's one of those somewheres in the Makefile, istr
[03:26:28] <cradek> I don't see what's wrong with an explicit list, fwiw
[03:26:46] <seb_kuzminsky> jepler: it's NOCVS ;-)
[03:26:56] <jepler> $(call NOCVS, ...) then
[03:27:23] <seb_kuzminsky> cradek: well, the hm2-stepper and hm2-servo configs were not getting included in the .deb, because i didnt know to add them to the CONFIGS list in addition to adding them to the configs dir
[03:27:38] <seb_kuzminsky> wildcarding it seems simpler to me
[03:27:42] <seb_kuzminsky> less error prone
[03:27:57] <seb_kuzminsky> PROCEED (Y/N)?
[03:29:23] <SWPadnos> REDO FROM START
[03:29:25] <cradek> I have no opinion other than the previously stated one :-)
[03:38:08] <seb_kuzminsky> there's another copy of the list of configs in COPY_CONFIGS
[03:38:20] <jepler> seb_kuzminsky: ah but that's diffrant
[03:38:25] <jepler> (sic)
[03:38:36] <jepler> not everything gets copied to every config
[03:38:38] <seb_kuzminsky> i see, it sort of is
[03:38:39] <seb_kuzminsky> right
[03:38:52] <jepler> there's maybe one thing (emc.nml?) that's copied to every config...
[03:38:57] <seb_kuzminsky> normally we use symlinks for that, and put the symlinks in the revision control system
[03:39:08] <seb_kuzminsky> but i wont whine about CVS any more tonight ;-)
[03:39:09] <SWPadnos> var file too, maybe
[03:39:30] <cradek> but when installed you don't want them to end up as symlinks (I think)
[03:39:51] <SWPadnos> for the sample configs, it shouldn't matter (I think)
[03:39:52] <seb_kuzminsky> why not?
[03:40:00] <SWPadnos> since in theory users can't modify them anyway
[03:40:17] <cradek> cp -r /etc/emc2/sample-configs/whatever ~/emc2/configs
[03:40:32] <cradek> suddenly your -> ../common/whatever.nml has screwed the user
[03:41:07] <SWPadnos> is there a cp flag that will copy the linked file instead of a copy of the link?
[03:41:16] <cradek> and -> /etc/..../whatever.nml is just another form of screwage
[03:41:48] <seb_kuzminsky> cradek: that's a valid point
[03:44:00] <jepler> because you still can't zip it up, send it to chris, and have him be sure what your config is
[03:44:17] <cradek> that too
[03:44:39] <jepler> (like with micges, where the problem he saw was 4x as bad as the problem we finally saw due to something in his hal file he hid from us)
[03:45:23] <cradek> fortunately I missed that one
[03:45:26] <jepler> that reminds me, I never actually filed an sf issue about it
[03:45:36] <jepler> cradek: did you see it in scrollback? care for the summary?
[03:45:44] <jepler> there is an actual bug involved in all this
[03:45:45] <cradek> I didn't, please
[03:46:47] <jepler> when running G1 F500 exactly along X, he reported that the AXIS DRO showed 500 (/min), but ddt showed 6.9 (=417/minute)
[03:47:13] <jepler> he showed a .ini file that he said exhibited the problem, but it wasn't one that any of us could run
[03:47:35] <jepler> I finally made some guesses and got a modified sim_mm.ini that showed a similar difference in velocity
[03:47:47] <jepler> it's when SERVO_PERIOD is not an integer multiple of BASE_PERIOD
[03:47:57] <cradek> huh
[03:48:02] <cradek> funky
[03:48:16] <jepler> e.g., with BASE_PERIOD=150us SERVO_PERIOD=1ms, you actually get SERVO_PERIOD=1.05ms but some parts of motion use 1ms as a basis for calculations
[03:48:26] <SWPadnos> and maybe also that the resultant SERVO/BASE periods aren't the same as the ini requests
[03:48:37] <jepler> the part he hid from us is that he additionally created a 300us threa, so his true SERVO_PERIOD was 1.2ms
[03:49:29] <cradek> sounds like that might be pretty pervasive
[03:49:43] <SWPadnos> oh interesting
[03:49:47] <SWPadnos> there's the 5/6 ratio
[03:50:22] <jepler> (now I think that he's also tickling another bug, because his thread creation order must either be 150us / 1ms / 300us or 300us / 150us / 1ms, both of which are supposed to be forbidden..
[03:50:27] <jepler> )
[03:50:48] <jepler> (because the 150us / 1ms are both created by motion, and he pasted a line showing that the other 300us is created by threads)
[03:51:11] <cradek> if he loads threads after motion isn't it fine?
[03:51:22] <jepler> no idea, he never showed his hal files
[03:51:26] <cradek> guh
[03:51:39] <jepler> but no, it shouldn't be allowed to create a 300us thread after a 1ms thread as I understand it
[03:51:45] <jepler> the frequency is supposed to be monotonic
[03:51:56] <jepler> and the fastest, first
[03:52:22] <cradek> Threads must be cre‐
[03:52:22] <cradek> ated in order, from fastest to slowest.
[03:52:27] <cradek> you are right
[04:01:44] <jepler> filed:
https://sourceforge.net/tracker/index.php?func=detail&aid=2478266&group_id=6744&atid=106744
[04:01:48] <jepler> goodnight
[04:03:04] <seb_kuzminsky> good night jeff
[04:03:06] <skunkworks> jepler: good night
[06:40:55] <CIA-46> EMC: 03cmorley 07TRUNK * 10emc2/configs/common/configurable_options/ladder/ (estop.clp serialmodbus.clp): Fix the ladder programs to clean them up of errors and ugly symbol names
[06:43:23] <seb_kuzminsky> timestamps on emc-commit messages are off
[06:43:32] <seb_kuzminsky> on the emc-commit emails i mean
[06:43:36] <seb_kuzminsky> goodnight...
[10:16:10] <christel> [Global Notice] As Chatham Island, NZ enters 2009 I'd like to wish each and every one of our users a very happy New Year! As normal #freenode-newyears is open and you're welcome to join us there! We may send the occasional wallop over the next day, however, this will be the only global notice. If you wish to see further messages from staff please set yourself +w.
[12:44:54] <micges> jepler, cradek: www.pastebin.ca/1297055
[12:45:52] <micges> this is rest information that you metioned yesteday night
[12:46:40] <micges> hal file with creation of thread out of order of speed
[12:47:52] <micges> it's working in 2.2.8 2.2 branch and trunk
[12:54:59] <alex_joni> micges:
https://sourceforge.net/tracker/index.php?func=detail&aid=2478266&group_id=6744&atid=106744
[12:58:36] <micges> yes but that info is to second bug (out of order creation of threads)
[12:59:29] <alex_joni> the out of order creation shouldn't be possible
[12:59:43] <alex_joni> probably some check fails, but that can easily enough be fixed
[13:00:03] <alex_joni> the problem is that if we fix it, then you won't be able to load the threads you want/need
[13:00:16] <micges> yes but I have 300us 150us 1ms
[13:00:18] <alex_joni> so it might be a bit more untrivial to fix
[13:00:36] <alex_joni> right, and you should have 150us, 300us and 1ms
[13:00:51] <alex_joni> 300us, 150us, 1ms shouldn't be possible
[13:01:42] <micges> I will change additional period to 250us (must reconfigure all machines but it is possible)
[13:02:41] <alex_joni> that will make the 1st bug (speed not quite right) go away
[13:03:46] <micges> yes, I request pid-thread speed due to PID loop not to be integer multiply of BASE
[13:04:58] <micges> but I don't know if every machine can have 4khz PID loop
[13:05:17] <micges> I have 3,3khz only on very fast ones
[13:05:33] <micges> rest have 2khz
[13:06:03] <micges> will see
[13:06:04] <alex_joni> why don't you want to have an integer multiply of BASE?
[13:06:44] <micges> not every multiply of those worked iirc
[13:07:42] <micges> now when I know sure that is a bug I will write those configs that didn't load
[13:07:44] <alex_joni> with HAL each thread is a multiply of the base thread
[13:09:09] <micges> yes in theory everything is fine but on machine that's not that simple(I have few times mentioned that with threads something is wrong)
[13:09:49] <micges> I don't have time to fix so I bypass most of problems :|
[13:12:37] <micges> but in new year I want to fix all problems not bypass
[13:13:15] <micges> first new thing will be automatic toolchanger
[13:17:55] <micges> alex_joni: did you saw wiki page created by jepler about 2.3 ?
[13:18:01] <alex_joni> yup
[13:18:38] <micges> what about joint/axes fixup ?
[13:19:04] <micges> you didn't make it to 31.01 ?
[13:19:10] <alex_joni> that he's correct
[13:19:35] <alex_joni> nope, not by myself, and currently there's not many people interested in it (other priorities)
[13:21:33] <alex_joni> bbl
[13:56:42] <jepler> micges: if you don't want the emc motion controller to create a base thread, then set its period to 0 or to SERVO_PERIOD.
[13:57:01] <jepler> if you need a no-fp thread faster than your 300us thread, then create it also with threads
[14:01:45] <micges> ok thanks
[14:06:25] <jepler> http://emergent.unpy.net/files/sandbox/bogus_thread_setup.hal
[14:07:11] <jepler> so with your configuration you actually are getting a base_period equal to 300us despite requesting 150us, because it rounds up to a multiple of the basic thread time
[14:09:27] <micges> ok I see
[14:12:33] <jepler> and here's how to get the base-thread without floating point, if it is required:
http://emergent.unpy.net/files/sandbox/threadq.hal
[14:12:58] <jepler> (note that there's still the 5% deviation and you'll hit the other bug in the motion controller; change 1000000 to 1050000 to avoid that)
[14:14:24] <jepler> (or you can test the patch I proposed on that sf bug report, if you're brave)
[14:16:50] <micges> interesting..
[14:17:04] <micges> I'll also test your patch :)
[14:38:50] <micges> happy new year to all
[14:53:47] <CIA-1> EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/halcmd_commands.c: line up columns and add a newline at the end of a message
[15:07:32] <CIA-1> EMC: 03flo-h 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/ (stepconf.glade stepconf.py): Added unit label for Scale, addes some Space between text and units, added missing shortcut and doublepoints
[15:17:58] <jepler> jmkasunich: is the intention that this hal configuration should be an error? (specifically, the way the second thread requests 150us but gets 300us; the same as the first thread created) surprisingly to me, it doesn't error but doesn't give anything like the requested periods either.
http://emergent.unpy.net/files/sandbox/bogus_thread_setup.hal
[15:49:46] <jmkasunich> jepler: "intention" is a tough question
[15:50:19] <jmkasunich> in RT code, my goal is always to do something sensible and carry on - since you can't just quit in RT code
[15:50:44] <jepler> but this is in thread creating code, which is setup-time stuff
[15:50:44] <jmkasunich> but that isn't RT code - I probably should have done better error checking and reject "inverted" periods
[15:51:27] <jepler> in fact, I see that there are these two error messages:
[15:51:27] <jepler> "HAL_LIB: ERROR: new thread period %ld is less than clock period %ld\n",
[15:51:31] <jepler> "HAL_LIB: ERROR: new thread period %ld is less than existing thread period %ld\n",
[15:51:53] <jmkasunich> yeah, I was just gonna say that a comp like threads doesn't have a nice way to tell the user what went wrong
[15:51:54] <jepler> but I think the code that checks for the first condition is buggy
[15:52:21] <jmkasunich> oh
[15:52:28] <jmkasunich> well, fix it!
[15:52:31] <jmkasunich> ;-)
[15:52:32] <jepler> heh
[15:52:50] <jepler> next question for you, while you're here
[15:53:02] <jmkasunich> hang on a sec (I'm not going away right away)
[15:53:07] <jepler> ok
[15:53:10] <jmkasunich> are those messages in threads, or in hal_lib?
[15:53:13] <jepler> those are in hal_lib
[15:53:31] <jmkasunich> I guess it doesn't matter tho, that function will be invoked from threads, in kernel context
[15:53:54] <jmkasunich> the whole "threads" component is a kluge
[15:54:04] <jepler> yes, but I don't want to get into that right now :-P
[15:54:10] <jmkasunich> if threads were created from halcmd itself, it could do better messages, etc
[15:54:12] <jmkasunich> OK
[15:54:29] <jmkasunich> next question? ;-)
[15:54:51] <jmkasunich> oh, I just remembered something else
[15:54:54] <jepler> you may have seen in scrollback or in your e-mail about this bug in the motion controller because it makes some calculations based on requested periods, not actual periods
[15:54:59] <jmkasunich> right
[15:55:19] <jmkasunich> there is a way for any hal function to know what the actual period is, so you don't need to add a HAL call
[15:55:22] <jepler> if it turns out to be difficult to restructure motion to fix that, do you think that it's OK to add a function like this to the public HAL API?
[15:55:25] <jepler> +unsigned long hal_thread_period(const char *name)
[15:55:31] <jmkasunich> I think (but haven't checked) that the period is passed into the function
[15:55:53] <jepler> I know there's the 'period' argument to the function; but motion does some setup before any rt function is actually called
[15:56:14] <jmkasunich> oh
[15:56:24] <jepler> (that's the root of the bug and I'm worried it may turn out to be difficult to fix)
[15:57:17] <jmkasunich> motion is unique in that it creates threads and does its own addfs
[15:57:34] <jmkasunich> that give it the unique ability to cheat
[15:57:35] <jepler> (does it 'addf'?)
[15:57:42] <jmkasunich> it must
[15:57:51] <jepler> I think it presently relies on the user to add it to the right thread
[15:58:00] <jmkasunich> oh
[15:58:03] <jepler> so there are yet more ways to shoot yourself in the foot
[15:58:07] <jmkasunich> yeah
[15:58:15] <jmkasunich> thats what I meant by cheat
[15:58:35] <jmkasunich> all other comps can't possibly know their period till the first time they run
[15:58:47] <jepler> that's your design and it's perfectly sane
[15:58:50] <jmkasunich> so they are forced to do their timing calcs in the actual function
[15:58:54] <jepler> unfortunately the code here at the startup of motion is .. vintage
[15:59:21] <jmkasunich> what code (file)?
[15:59:36] <jmkasunich> motion.c?
[15:59:37] <jepler> src/emc/motion/motion.c:init_threads()
[15:59:42] <jepler> oops, it's meeting time here, bbl
[16:00:03] <jmkasunich> working on new years eve? suckage
[16:02:12] <jmkasunich> do the realtime control, and adds the functions to the threads.
[16:02:12] <jmkasunich> */
[16:02:20] <jmkasunich> err
[16:02:33] <jmkasunich> do the realtime control, and adds the functions to the threads.
[16:02:33] <jmkasunich> */
[16:02:37] <jmkasunich> ftw?
[16:02:50] <jmkasunich> duh
[16:02:59] <jmkasunich> one more time
[16:03:16] <jmkasunich> /* init_threads() creates realtime threads, exports functions to do the realtime control, and adds the functions to the threads.*/
[16:03:46] <jmkasunich> the actual code doesn't do the last step, I guess it is relying on addf from the user
[16:07:11] <jmkasunich> the part that has you worried is set(Traj|Servo)CycleTime() I assume
[16:12:36] <jmkasunich> after further thought, I think hal_thread_period() is a perfectly fine thing to add to the HAL API
[16:13:13] <jmkasunich> with this requirement "Call only from within user space or init code, not from realtime code."
[16:13:36] <jmkasunich> since it involves traversing the thread list looking for 'name', it will have to grab the mutex
[16:47:54] <jepler> back now
[16:48:45] <jepler> jmkasunich: if I can untangle motion so that it just calls setXxxCycleTime at the first thread invocation, I'll skip adding hal_thread_period() .. but if I can't do better easily, that's what I'll do
[16:48:52] <SWPadnos> the user could theoretically attach those motion functions to any thread, and can remove and re-add them later
[16:49:38] <SWPadnos> so the only way to make it work all the time is to detect the period (and changes to it) in the functions themselves, which already get the period
[16:50:03] <jepler> yes, "first" is an oversimplification that only reflects all the situations that a sane user would create
[16:50:26] <SWPadnos> heh
[16:52:09] <BigJohnT> SWPadnos: I did get the fwd rev to work on the GS2 but got an error about illegal data value...
[16:52:32] <SWPadnos> I saw that. I remember getting an error of that sort at Fest, but I don't recall why
[16:53:32] <BigJohnT> I also noticed that the pins in Show HAL configuration did not show the presets but the watch window did...
[16:53:45] <BigJohnT> or values for the pins I should say
[16:54:13] <SWPadnos> ?
[16:54:21] <SWPadnos> parameters or pins?
[16:54:30] <BigJohnT> pins with values
[16:54:39] <BigJohnT> but not the boolean ones
[16:54:46] <BigJohnT> they showed ok
[16:54:54] <SWPadnos> like which ones?
[16:55:17] <jmkasunich> jepler: static long unsigned int prev_period = 0; if (period != prev_period) { setXxxCycleTime; prev_period = period }
[16:55:25] <jmkasunich> that's the easy part of course
[16:55:26] <BigJohnT> I can't look right this second building emc
[16:55:33] <SWPadnos> actually, lets start at the beginning - what presets are you ralking about?
[16:55:38] <SWPadnos> or talking :)
[16:55:50] <jmkasunich> the hard part is figuring out the side effects of setXxxCycleTime
[16:56:02] <jmkasunich> (which I'm sure you already know, so I'll stop rambling(
[16:56:10] <BigJohnT> let this make finish then I'll look
[16:56:14] <SWPadnos> ok
[16:56:27] <SWPadnos> I was just wondering if you meant things in the drive or things set in a hal file
[16:57:13] <SWPadnos> what kind of slow-ass machine do you have? it's been over a minute already! :)
[16:57:41] <BigJohnT> p3 1000
[16:57:51] <BigJohnT> I did a make clean :/
[16:57:57] <SWPadnos> heh
[16:58:47] <BigJohnT> * BigJohnT runs out to the shop to add more wood on the fire...
[17:05:09] <BigJohnT> without setting any pins just loading gs2 in the show window gs2_vfd.motor-RPM is 0 and in the watch window it is 1730
[17:06:37] <BigJohnT> parameter gs2_vfd.motor-RPM shows 1730 in the show window
[17:07:01] <BigJohnT> hmmm you have a pin and a parameter with the same name...
[17:07:08] <SWPadnos> the show window doesn't refresh like the watch window does
[17:07:34] <BigJohnT> it will refresh if you click on something else and then back
[17:07:46] <SWPadnos> hey, I do have a pin and param with the same name :)
[17:07:54] <BigJohnT> could that be a problem?
[17:08:09] <SWPadnos> it's not a technical problem, but it could cause confusion
[17:08:17] <SWPadnos> I guess the param could be called motor-nameplate-RPM
[17:08:37] <SWPadnos> and then motor-nameplate-frequency
[17:08:52] <BigJohnT> what does the pin motor-RPM do?
[17:09:13] <SWPadnos> it sets the speed :)
[17:09:17] <SWPadnos> that's the input
[17:09:24] <SWPadnos> hmm
[17:09:25] <SWPadnos> no
[17:09:36] <SWPadnos> it's the actual motor speed as reported by the VFD
[17:10:19] <SWPadnos> so it should be 0, and the parameter 1730 (or whatever you set), when you first start up
[17:10:42] <BigJohnT> the 1730 was default as I recall
[17:10:47] <SWPadnos> ok, could be
[17:10:48] <BigJohnT> in the parameter
[17:10:51] <SWPadnos> yep
[17:11:22] <SWPadnos> anyway, one is feedback from the drive, and will remain at 0 when there are communication errors, or if the motor isn't turning
[17:11:39] <SWPadnos> (actually, it'll remain at the last value if there are comm errors)
[17:12:06] <BigJohnT> it is a bad value error not a comm error
[17:12:20] <SWPadnos> I understand
[17:12:31] <SWPadnos> just explaining a little more about the motor-RPM pin
[17:12:37] <BigJohnT> ok
[18:42:53] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/lathe/images/ (5 files): add some info on lathe tool table
[18:43:01] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/lathe/lathe-user.lyx: add some info on lathe tool table
[18:45:20] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/Stepper_Diagnostics.lyx: it didn't read well, don't know what drugs I was on when I wrote it
[18:47:00] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ (Submakefile docs.xml index.tmpl): add a couple of files to the html docs
[21:00:08] <BigJohnT_> BigJohnT_ is now known as BigJohnT
[21:53:28] <CIA-1> EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: Add HAL commands for estop ladder program
[22:03:23] <alex_joni> greetings from 2009 ;)
[22:06:58] <seb_kuzminsky> wow you're in 2009 already :-)
[22:14:03] <alex_joni> yeah, a bit early :)
[23:48:06] <cradek> alex_joni: how does it look so far?