Back
[14:09:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 05hy-vfd af3b1bb 06linuxcnc 10src/hal/user_comps/huanyang-vfd/hy_vfd.c hy-vfd: remove some dead code * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=af3b1bb
[14:09:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 05hy-vfd dcb33d8 06linuxcnc 10src/hal/user_comps/huanyang-vfd/hy_vfd.c hy-vfd: remove some dead code * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dcb33d8
[14:09:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 05hy-vfd 839f40d 06linuxcnc 03docs/man/man1/hy_vfd.1 hy-vfd: start adding a manpage * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=839f40d
[14:09:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05hy-vfd cd0a1c2 06linuxcnc 10src/hal/user_comps/huanyang-vfd/hy_vfd.c hy-vfd: fixup --help output * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cd0a1c2
[14:09:49] <KGB-linuxcnc> 03Sebastian Kuzminsky 05hy-vfd 8bd4451 06linuxcnc 10src/hal/user_comps/huanyang-vfd/hy_vfd.c hy-vfd: add copyright info to hy_vfd.c * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8bd4451
[14:20:48] <zeeshan|2> is it true that python userspace components run slower than c userspace components?
[14:24:24] <zeeshan|2> my mill vfd component is written in python, and my lathe vfd component is written in c. both seem to have lag. the lathe one bothers me more because when running CSS mode, there is like a .5 s to 1 s delay between commanded speed and actual speed.
[14:24:44] <zeeshan|2> (im using modbus serial to control speed) -- anyway to speed this up -- maybe down to .1s?
[14:25:50] <seb_kuzminsky> i think the speed of the serial communication is much much slower than the difference in speed between python and c
[14:26:13] <seb_kuzminsky> are both vfds using the same baud rate?
[14:26:45] <seb_kuzminsky> you'll probably not get good speed control through a serial-attached vfd no matter how cleverly you write the driver, is my guess
[14:39:12] <skunksleep> We got the mesa hardware... Now which machine to convert?
[14:49:04] <pcw_home> Python + serial delays are probaby still just a few mS
[14:49:05] <pcw_home> If you have .5 to 1 second delays, I suspect thats mainly in the drive firmware
[14:55:36] <skunksleep> I would think it pretty easy to figure out if the delay is linuxcnc or the drive
[14:56:10] <skunksleep> * halscoping signals
[15:03:33] <pcw_home> not sure if you can tell when the low level serial xmit is done
[15:05:43] <skunkworks> depends on what is exposed - I could see a pin that lets you know when the python routine is done - and then see how long the drives takes to respond..
[15:28:55] <jepler_> if you followed the sample in 'pydoc hal', it has a 1s delay between times it checks the pins
[15:28:58] <jepler_> while 1:
[15:29:00] <jepler_> imposed by the time.sleep call
[15:29:02] <jepler_> # act on changed input pins; update values on output pins
[15:29:05] <jepler_> time.sleep(1)
[15:30:07] <jepler_> having a hal output that the python program sets after it's transmitted its serial message or whatever is a good way to see whether the delay is before or after the serial transmit
[15:30:36] <jepler_> you can scope the component's input and output and just see onscreen how long it takes
[15:32:06] <pcw_home> also you might read something from the drive to avoid communication overruns (Though Im not too familar with modbus handshaking)
[15:32:07] <pcw_home>
[15:35:33] <jepler> if I recall serial modbus correctly, after the master sends a command it waits for a confirmation or response from the device, except in the case of broadcasts
[15:40:57] <pcw_home> Yeah, so you could look at the time till it responds (not that the tells you it changed the VFD frequency yet)
[15:54:13] <skunkworks> if he has spindle feedback - he can see..
[16:04:11] <zeeshan|2> seb_kuzminsky: both are using the same baud rate yes. 19200
[16:04:16] <zeeshan|2> ill try increasing it
[16:05:12] <zeeshan|2> and scoping what is causing the delay
[16:06:11] <pcw_home> 19200 is ~ 2000 chars/second so unless you have a pretty big message its probably not the main issue
[16:08:10] <zeeshan|2> ill spit the time out at send and recieve
[16:08:24] <zeeshan|2> like jepler said
[16:10:06] <pcw_home> yeah need intrumentation to see where the time goes...
[23:36:46] <seb_kuzminsky> does anyone know of any problems with the 2.7 branch? regressions since 2.6, new bugs, that kind of thing? it feels to me like 2.7.0-time is getting close
[23:37:30] <Tom_itx> i wish i could say i've tried it but life has gotten in the way recently
[23:38:01] <cradek> likewise, I wish I could say I've tried it on my lathe
[23:38:20] <cradek> I changed its hardware today, and now it doesn't work
[23:38:50] <Tom_itx> i was in the middle of updating my control when life hit me in the head
[23:39:04] <Tom_itx> it's still on the bench waiting for me to button it up
[23:39:39] <Tom_itx> had just added spindle control to it with rev etc and about to rejoin it to the mill
[23:43:12] <seb_kuzminsky> i'll open a bug ticket to give you guys your lives back
[23:52:30] <seb_kuzminsky> now we're out of date again:
https://bits.debian.org/2015/04/jessie-released.html
[23:53:04] <cradek> it's the human condition