#emc-devel | Logs for 2010-09-20

Back
[08:19:03] <ries_> ries_ is now known as ries
[13:40:11] <skunkworks_> logger_dev: bookmark
[13:40:11] <skunkworks_> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-09-20.txt
[13:57:29] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[18:57:40] <JT-Work_> JT-Work_ is now known as JT-Work
[20:09:43] <alex_joni> * alex_joni drops a needle
[20:21:44] <skunkworks> ting tinkle tinkle
[20:32:13] <andypugh> I am looking at writing the Hostmot2 driver for the Mesa 8i20 card (2.2kW 3-phase servo drive)
[20:32:27] <andypugh> I am trying to work out the best "pinout"
[20:33:26] <andypugh> The config modparam declares how many "smart serial" channels are to be enabled on the host FPGA card, and those can connect to (currently) 3 different accessory cards.
[20:34:28] <andypugh> My original idea was to simply expose the status/data registers of the sserial components and then drive those with external modules, chosen to suit the attached device.
[20:35:29] <andypugh> ie hm2_5i23.sserial.global.status and hm2_5i23.sserial.0.register0 etc.
[20:36:53] <andypugh> However, I am beginning to have a bit of a rethink, as the sserial peripherals report back a cookie, so could be configured at load-time, so we would end up with hm2_5i23.8i20.0.angle, hm2_5i23.8i20.0.current etc.
[20:37:36] <andypugh> This seems a lot neater, as it saves having easily-forgotten links between the hm2_5i23 driver and an external module.
[20:38:33] <andypugh> A typical setup would have 2x global and axes x 3 data registers.
[20:39:15] <jepler> do all the SPI-interface daughtercards have "cookies"?
[20:39:45] <andypugh> I believe so.
[20:40:13] <andypugh> It isn't SPI as such, as far as I know.
[20:40:28] <andypugh> I think it is Mesa's own serial protocol.
[20:41:02] <jepler> oh, I see now that the 8i20 is RS-422 @ 2.5Mbps
[20:41:20] <seb_kuzminsky> nifty
[20:41:59] <andypugh> Hi Seb
[20:42:11] <jepler> I agree: if you can autodetect the devices, there's no reason to force the user to enter information about them
[20:42:19] <seb_kuzminsky> i think it makes sense for the hostmot2 driver to export a serial port at the kernel level, not at the hal level, and have a separate 8i20 driver load and attach to the serial port in the kernel, and export its own hal pins
[20:42:27] <andypugh> Do you think it is reasonable for the hm2 driver to poll the daughtercards at startup and create pins to suit/
[20:42:35] <seb_kuzminsky> yes
[20:43:09] <andypugh> I just read the answer you wrote before I asked the question :-)
[20:44:32] <andypugh> It definitely avoids exporting HAL pins with non-human-comprehensible data on them.
[20:45:00] <andypugh> Which seems "right"
[20:45:40] <seb_kuzminsky> and avoids trying to stuff stream-like communications (such as a serial port) into a shared-memory scalar-like communication provider (like hal)
[20:46:12] <andypugh> Yes, I was wondering how that would work out, it would need buffers and state-machines and other complications.
[20:46:27] <seb_kuzminsky> yeah: yuck
[20:46:35] <seb_kuzminsky> better off making some new abstraction outside of hal
[20:47:13] <andypugh> OK, all that remains now is to actually do it :-)
[20:47:18] <seb_kuzminsky> heh
[20:48:15] <andypugh> This looks a bit more complicated than the LED driver.
[20:48:38] <andypugh> I wonder what to call the modules in the modparam?
[20:49:05] <andypugh> num_sserial? num_sslbp? num_rs422?
[20:49:18] <seb_kuzminsky> if they're rs422 i think you should call them that
[20:49:43] <seb_kuzminsky> if there's some funny extension or incompatibility, then dont use rs422
[20:50:12] <andypugh> The 8i20 docs call is SSLBP
[20:51:09] <andypugh> I guess I can ask Pete. It isn't a hard thing to change anyway, the 3-phase-pwm components changed name twice.
[21:13:54] <PCW> andypugh, the status register will tell you the external device so an appropriate name would be good
[21:13:56] <PCW> (the RS-422 part is not visible to the driver, only parallel registers for parameters and data)
[21:14:59] <andypugh> I was going to use 8i20 for the pins themselves, so you would have hm2_5i23.0.8i20.0.phase-angle (or similar)
[21:15:12] <alex_joni> see that your 6th sense is still working ;)
[21:15:27] <PCW> ;-)
[21:16:04] <andypugh> My only question was what to call the generic smart-serial interface in the config line (where currently we state num_encoders=3, num_stepgens=2)
[21:16:24] <PCW> NOte that the SSLBP will also support the 7I64 and a couple of new cards we dont have a names for yet
[21:16:59] <andypugh> You do realise that your nam-space only allows for 1000 products?
[21:17:11] <alex_joni> ha
[21:17:39] <andypugh> So, num_sslbp=8 would suit as a parameter?
[21:17:41] <alex_joni> 6o43 ?
[21:17:45] <PCW> Yes its sort of a mess now as the low level firmware ID only knows its a sserial not that it has a SSLBP ROM (Ill retire when I get to 1000)
[21:18:16] <andypugh> Right, so sslbp is a sub-set of sserial?
[21:18:35] <PCW> The driver can probe the Firmware type (SSLBP MODBUS etc)
[21:18:36] <andypugh> In that case I will use num_sserial
[21:19:14] <andypugh> What does SSLBP stand for?
[21:19:37] <alex_joni> slow serial low baud protocol
[21:19:41] <PCW> SS for smart serial and LBP for our LittleBinaryProtocol
[21:21:07] <PCW> We have a minor change in the status regs to make heterogeneous remote devices easier to deal with, Ill send you the updated firmware and manual
[21:21:19] <andypugh> So, fairly proprietery then :-)
[21:21:55] <PCW> Well its open and documented in the manual
[21:22:57] <andypugh> Perhaps "proprietary" (even spelled correctly) was not quite the right word.
[21:23:33] <alex_joni> custom ;)
[21:24:08] <PCW> Thats better (we use it a lot even for our USB stuff)
[21:24:54] <PCW> basically maps 64K range register access onto a simple serial stream
[21:27:14] <PCW> Looks like we can run the 8I20 at close to 10 KHz update rate (servo thread rate) with SSLBP (though 4 KHz would be more comfortable)
[21:34:16] <andypugh> I guess that means I have to keep the driver fast then?
[21:36:37] <PCW> I though computers were fast now...
[21:36:54] <PCW> (t)
[21:38:37] <andypugh> Yes, but I can make them slow