Back
[00:01:45] <SWPadnos> there is no generic modbus driver, but there are now several modbus-based drivers for specific devices
[00:02:08] <SWPadnos> they are all userspace components, so they are not suitable for monitoring limit switches
[00:02:43] <SWPadnos> there is a sample implementation of a realtime module that directly interfaces to a serial port, which could be used to make a component that you think will be realtime
[00:03:25] <SWPadnos> (but it won't really be, since there's no guarantee that a serial command/response exchange will happen in a given amount of time)
[00:04:15] <voxadam> So Modbus isn't really suitable for RT control regardless of how/where it's implemented?
[00:08:27] <voxadam> Why can't the command/response exchange time be guaranteed? Is it a limitation of Modbus itself or is it an implementation issue?
[00:10:48] <SWPadnos> it's a serial port issue
[00:11:12] <SWPadnos> what happens if there's a glitch at some point in the transmission of either the command or the response?
[00:11:34] <SWPadnos> A: you get a message with a bad CRC, and therefore have no new information from that exchange
[00:12:25] <SWPadnos> a single bit error will invalidate the entire command/response set (luckily - the alternative is to get some bad data)
[00:13:49] <SWPadnos> so although it's possible to make a driver that sends and receives bytes from a realtime thread, there is no guarantee that the bytes will actually get through to the other end, nor that there will be a response within the time frame you'd like
[01:08:06] <pcw_home> I think I disagree, Error checking is a good thing, Getting CRC errors indicates a hardware fault
[01:08:08] <pcw_home> If you treat a CRC error as a fatal error you have realtime and error checking (certainly better than not checking = step+dir or quadrature or SPI)
[01:11:16] <SWPadnos> well, a single bit error is possible with serial, and probably shouldn't kill the machine
[01:11:31] <SWPadnos> many bad CRCs in a short time probably should
[01:11:57] <SWPadnos> and a driver can check for that, also can check that there is "recent" data (for some settable value of "recent"), etc.
[01:12:42] <pcw_home> I would expect 100s of billions of transactions error free on a good link
[01:19:11] <pcw_home> Any errors most likely means insufficient noise margins
[01:21:12] <SWPadnos> in a noisy environment, using consumer serial interfaces (ie, RS-232 rather than RS-485, with ICs that do one sample per bit ...), I would expect a little more
[01:21:26] <SWPadnos> but you're right, it will be fine most of the time
[01:21:44] <SWPadnos> I just wouldn't stick limit or E-stop switches on a modbus I/O device
[01:22:32] <SWPadnos> though a software (RT of course) watchdog could also shut things down if there isn't enough information successfully received over the serial link
[01:23:24] <pcw_home> Well serial modbus would be too slow with standard host side hardware anyway
[01:24:04] <SWPadnos> ?
[01:24:18] <SWPadnos> what do you mean by "host side hardware"?
[01:24:35] <pcw_home> Standard com port/RS-232
[01:24:43] <SWPadnos> oh
[01:25:27] <SWPadnos> sure, you're not going to get 1000 updates/sec with that
[01:25:51] <pcw_home> This error stuff is something we've been working on a bit for a HostMot2 interface to the 8I20 (and other serially connected drives)
[01:26:56] <pcw_home> We have it working pretty well now (4K updates/sec possible with 8 drives/ smart serial)
[01:26:59] <SWPadnos> yeah, it always sounds simple but ends up not really being that way :)
[01:27:02] <SWPadnos> nice
[01:27:13] <SWPadnos> some few-MHz SPI?
[01:27:52] <pcw_home> No just serial RS-422 async at 2.5 MBaud
[01:28:39] <pcw_home> (fewer isolators and we can connect to a PC serial port /USB/serial adapter for setup)
[01:29:02] <SWPadnos> ah, cool
[01:31:19] <pcw_home> The HostMot2 interface is just parallel registers (write torque/angle, read bus voltage/ temperature)
[01:31:20] <pcw_home> serial xmits are initiated by the host side write
[07:24:22] <Jymmm> Jymmm is now known as Jymmmmmmmmmmm
[07:26:43] <Jymmmmmmmmmmm> Jymmmmmmmmmmm is now known as Jymm
[07:54:58] <micges_work> jepler: your emccalib patch works fine on rt machine
[08:51:34] <ries_> ries_ is now known as ries
[09:50:00] <ries_> ries_ is now known as ries
[12:32:11] <CIA-2> EMC: 03jepler 07v2.4_branch * r2f96e7c39f23 10/tcl/bin/emccalib.tcl: emccalib: fix crash 'unmatched open quote in list'
[12:32:13] <CIA-2> EMC: 03jepler 07v2.4_branch * r0dea04057323 10/src/hal/components/stepgen.c: fix ctrl_type on certain 2.6.3x kernels; allow empty ctrl_types
[13:20:47] <steve_stallings> steve_stallings is now known as steves_logging
[13:25:05] <SteveStallings> SteveStallings is now known as steves_logging
[13:52:50] <SteveStallings> SteveStallings is now known as steves_logging
[14:08:34] <Jymm> Jymm is now known as Jymmm
[16:18:07] <ries_> ries_ is now known as ries
[17:03:22] <mozmck> how do I run the runtests again?
[17:19:59] <micges> goto scripts/ and type ./runtests
[18:07:40] <andypugh> Interesting question: if somebody writes a component for EMC, can they keep it proprietary and make money from it?
[18:08:49] <andypugh> Supplementary question, why do I feel annoyed by the concept when I have spent a lot of time helping with it for free? After all, the outcome as far as I am concerned is the same.
[18:11:59] <cradek> it does appear to me at first glance that you can make a nonfree HAL component, because rtapi.h and hal.h are LGPL
[18:13:44] <cradek> the second question about your feelings I cannot answer, I can only sympathize :-)
[18:14:01] <andypugh> But I guess there is nothing stopping me producing a free variant of the same thing under the GPL?
[18:14:39] <cradek> you are always free to write whatever software you want under whatever license you want, if it's your own work
[18:15:08] <cradek> (or at least I hope that's true in our increasingly-crazy world)
[18:16:22] <andypugh> To be fair to the guy, he is brand new to programming, so grasping the Open Source philosophy might take time.
[18:17:34] <cradek> oh I thought this was just hypothetical.
[18:18:32] <andypugh> It is at the moment.
[18:19:19] <andypugh> I showed him the GPL. I can't be bothered to read it myself in enough detail to answer the question.
[18:19:37] <cradek> haha
[18:19:41] <SWPadnos> I believe the HAL programming interfaces were made LGPL explicitly to allow e.g. a manufacturer to write a closed-source driver for their hardware
[18:20:51] <SWPadnos> on the second question, if someone is intending to make money from something you helped them write, you might be able to put moral pressure on them to release it as Free software, especially if they didn't tell you they were planning on keeping it proprietary before you helped
[18:21:22] <cradek> anyone, manufacturer or not, who wants to work with the rest of us is doing him/herself a huge disservice if he/she uses an incompatible license
[18:21:46] <SWPadnos> but only if that license is disclosed after they got help ...
[18:22:12] <SWPadnos> (I agree with you, but of course we're easy to exploit if someone really wants to)
[18:22:46] <cradek> heh, speak for yourself
[18:22:51] <SWPadnos> ok, will do :)
[18:23:17] <SWPadnos> I guess I meant that we rarely ask what license someone expects to use when they first ask for help
[18:30:18] <jepler> The easiest way to make sure you don't run afoul of any license issues with emc is to license anything that incorporates parts of emc is to license the software under GPLv2+.
[18:32:17] <andypugh> I doubt it will come to that, I think it is a guy thinking "hey, actually, this could be really useful, and nobody else has it at the the moment". I am not sure what he could do if I asserted my part of the IP (as could cradek, incidentally) and refused to sell it to him.
[18:32:55] <cradek> oh I helped on this too?
[18:33:01] <cradek> * cradek sighs
[18:33:26] <andypugh> Not directly, but it is a modified version of rotatekins.