#linuxcnc-devel | Logs for 2018-09-06

Back
[01:02:09] -!- c-log has quit [Ping timeout: 252 seconds]
[01:08:11] -!- c-log has joined #linuxcnc-devel
[02:35:07] -!- ve7it has quit [Remote host closed the connection]
[03:14:21] -!- Robh__ has joined #linuxcnc-devel
[05:18:48] -!- njh has quit [Ping timeout: 252 seconds]
[06:07:34] -!- MarkusBec has quit [Ping timeout: 268 seconds]
[06:12:50] -!- Robh__ has quit [Ping timeout: 244 seconds]
[06:20:58] -!- MarkusBec has joined #linuxcnc-devel
[07:19:48] -!- c-log has quit [Ping timeout: 252 seconds]
[07:21:55] -!- c-log has joined #linuxcnc-devel
[07:34:15] -!- jthornton has quit [Quit: Leaving]
[07:34:35] -!- jthornton has joined #linuxcnc-devel
[07:41:30] <jthornton> when using the software stepgen component with the parallel port is it possible to have different step and direction timings for each stepgen?
[07:42:40] <jthornton> for example if I had 3 gecko 203v's and 1 gecko 201 the step and direction timings are different
[07:44:12] -!- Robh__ has joined #linuxcnc-devel
[07:45:10] <rmu|w> jthornton: settings for G201 should work for G203
[07:46:15] <jthornton> that's not my question :)
[07:47:25] <jthornton> and no the timing for a g203v will not work with a g201 because the 201 direction setup is 20000 and the 203v is 2000
[07:49:05] <rmu|w> but the timing for a g201 will work with a g203
[07:49:47] <rmu|w> the man page says you can specify timings per stepgen
[07:52:46] <jthornton> I missed that
[07:53:00] <rmu|w> with software-stepgen, signals are always at least one thread period long anyways, except if you use those "auto-reset" feature of the parport module
[07:54:18] <rmu|w> http://linuxcnc.org says parameters are specified as stepgen./N/.parameter, /N/ being the instance number of stepgen
[07:58:06] <jthornton> yea I've been staring at the man page for the last hour lol
[08:00:16] <rmu|w> direction setup means hold direction signal AT LEAST AS LONG as direction setup time before doing a step
[08:02:33] <jthornton> I'm programming a parallel port configuration tool in pyqt5 for 2.8 so I'll have drive timing on each joint
[08:04:40] <rmu|w> i suggest having editable driver presets and choosing the preset per joint
[08:06:11] <jthornton> https://imagebin.ca
[08:06:20] <jthornton> that is what I have now
[08:11:54] <jthornton> looks like to get the minimum base period I need to find the highest step time and step space
[08:19:24] <rmu|w> is that a question? minimum base period is determined by latency
[08:20:12] <rmu|w> if you need step frequency that is higher than 1/base period then tough luck
[08:20:19] <jthornton> https://paste.ubuntu.com
[08:20:54] <jthornton> that's pretty much the code from stepconf
[08:22:15] <jthornton> time to hit the shower and start my real work
[09:15:56] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15rene-dev pushed 1 new commit to 06master: 02https://github.com/LinuxCNC/linuxcnc/commit/88ba2eb2516d24a749a19466160d07c2b94cfa8a
[09:15:56] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06master 1488ba2eb 15Rene Hopf: make interpreter code more readable by using Modal group defines...
[09:19:38] -!- Robh__ has quit [Ping timeout: 245 seconds]
[09:56:07] -!- MarkusBec has quit [Ping timeout: 240 seconds]
[10:15:42] -!- MarkusBec has joined #linuxcnc-devel
[10:56:17] <pcw_home> There's no real reason not to use 20000 or even 50000 for the setup/hold times for _any_ drive (at least with the software stepgen)
[10:59:56] <pcw_home> similar thing with step timings in general the should greater than the drives minimums but people tend to set them at the minimums (often causing flaky behaviour, temperature sensitivity etc)
[11:09:17] Jin|away is now known as Jin^eLD
[11:09:21] <Jin^eLD> hi
[11:22:27] <JT-Shop> pcw_home: thanks
[11:22:53] <JT-Shop> should you still try and use doublestep?
[11:28:05] <pcw_home> doublestep?
[11:32:27] -!- njh has joined #linuxcnc-devel
[11:35:30] <JT-Shop> yea if you set the step space to 0 you can get two steps per period
[11:36:57] <JT-Shop> http://linuxcnc.org
[11:42:23] <pcw_home> You can get _one_ step per base period using reset
[11:42:43] <pcw_home> otherwise you get a step every other base thread
[11:43:11] <rene_dev_> pcw_home why not always have 50% duty cycle on the step pin, thats how other controllers handle that. requires no timing shit at all
[11:43:44] <pcw_home> Bad for OPTO life mainly
[11:45:40] <pcw_home> IF you want 50%, quadrature is better in every way
[11:45:57] <rene_dev_> quadrature is always better in every way ;D
[11:46:09] <rene_dev_> how does that affect opto life?
[11:46:43] <pcw_home> LED on-time is a life limiting thing on OPTOs
[11:47:23] <pcw_home> unfortunately most step drives use really crappy OPTOS
[11:47:31] <rene_dev_> yeah, but pepole that are using softstepping are mostly using $10 china breakouts
[11:47:42] <pcw_home> Yeah
[11:49:30] <rene_dev_> and cheap drives :D
[11:53:54] <rene_dev_> but the dir pin also has a 50% duty cycle
[11:54:02] <rene_dev_> so no point in having the other opto last longer
[11:56:21] <pcw_home> yeah but may be lower current / higher CTR degradation resistant
[11:58:26] <pcw_home> thats is the step OPTO pin needs to have a stiff pullup on the transistor side for speed so may not tolerate CTR degradation as well
[11:59:41] <pcw_home> on the other had most cheap drives have no reverse input protection on the OPTOS and even tiny ESD will reduce the CTR markedly
[12:03:59] <pcw_home> One minor issue for software stepping is that you can't do 50% with the double step option
[12:04:46] <pcw_home> or you would not want to anyway (spin too long)
[13:51:26] -!- Robh__ has joined #linuxcnc-devel
[14:22:07] -!- jthornton has quit [Ping timeout: 240 seconds]
[14:22:12] -!- JT-Shop has quit [Ping timeout: 252 seconds]
[14:24:27] -!- jthornton has joined #linuxcnc-devel
[14:33:55] -!- JT-Shop has joined #linuxcnc-devel
[15:36:43] -!- ve7it has joined #linuxcnc-devel
[17:12:54] <jepler> https://www.renesas.com shows CTR declining by <50% in 2e5 hours ~= 23 years, not sure I believe it. The next table, which shows that merely by keeping your optos at -25C you get a 1140 year operating lifetime seems more suspect still. (Figures 4 and 5)
[17:17:21] <jepler> and all without discussing duty cycle hm
[17:28:40] <pcw_mesa> Yeah, I dont trust the OPTOS in Chinese drives much OTOH the electrolytic caps probably only last a couple years on a hot drive so maybe its not an issue
[18:12:05] Jin^eLD is now known as Jin|away
[18:26:00] -!- JT-Shop has quit [Read error: Connection reset by peer]
[18:27:51] -!- JT-Shop has joined #linuxcnc-devel
[18:47:31] -!- Roguish_ has joined #linuxcnc-devel
[18:48:46] -!- Roguish has quit [Ping timeout: 250 seconds]
[18:49:57] -!- Roguish has joined #linuxcnc-devel
[18:53:04] -!- Roguish_ has quit [Ping timeout: 240 seconds]
[19:05:27] -!- c-log has quit [Ping timeout: 252 seconds]
[19:07:05] -!- c-log has joined #linuxcnc-devel
[19:55:42] -!- Robh__ has quit [Ping timeout: 252 seconds]
[20:08:56] -!- JT-Shop has quit [Read error: Connection reset by peer]
[20:09:22] -!- jthornton has quit [Read error: Connection reset by peer]
[20:09:25] -!- JT-Shop has joined #linuxcnc-devel
[20:12:47] -!- JT-Shop has quit [Read error: Connection reset by peer]
[20:31:32] -!- jthornton has joined #linuxcnc-devel
[20:32:34] -!- JT-Shop has joined #linuxcnc-devel
[21:07:47] -!- ve7it has quit [Remote host closed the connection]
[21:09:26] -!- ve7it has joined #linuxcnc-devel
[21:29:11] -!- Roguish has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
[22:03:59] -!- JT-Shop has quit [Read error: Connection reset by peer]
[22:04:45] -!- jthornton has quit [Ping timeout: 252 seconds]
[22:20:03] -!- jthornton has joined #linuxcnc-devel
[22:21:08] -!- JT-Shop has joined #linuxcnc-devel