On 10/24/12 12:01 , Victor Rocco wrote: > -----Mensaje original----- > De: Sebastian Kuzminsky [mailto:[email protected]] > Enviado el: Miércoles, 24 de Octubre de 2012 01:40 p.m. > Para: Michael Haberler; [email protected] > Asunto: Re: Fwd: [Emc-developers] I would like to contribute a "modbus to > hal" component, AKA mb2hal. > > On 10/24/12 10:16 , Michael Haberler wrote: >> Anfang der weitergeleiteten E-Mail: >> >>> Von: Victor Rocco <[email protected]> >>> Betreff: RE: [Emc-developers] I would like to contribute a "modbus to > hal" component, AKA mb2hal. >>> Datum: 24. Oktober 2012 17:46:14 MESZ >>> An: "'Michael Haberler'" <[email protected]> >>> >>> Michael, >>> >>> I just see that you have commited mb2hal in master. Thanks you for > that!. >>> I have to tell you that the patch file that you have deleted later in >>> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commit;h=ca835b429478 >>> 324639d >>> f779e26005ca43b8917d1 >>> is necessary for the correct functioning of some transactions in >>> mb2hal (see the LogBook.txt). >>> It was included as a patch because it modifies >>> hal/user_comps/modbus.c wich is used by gs2_vfd.c. I don't have how >>> to test that VFD drive, so it was included as a patch to exclude the >>> risk of a broken gs2_vfd.c >>> >>> The file modbus.c is an old libmodbus(1?) file, wich have some bugs >>> and lacks of Modbus functions. In order to do not depend on that >>> file, i am currently modifying mb2hal to use libmodbus3, like your >>> own vfs11_vfd.c. I think it will be available in two weeks. >>> After that will be easy to add more modbus transactions in mb2hal, >>> because they are already implemented in libmodbus3. >>> >>> Thanks you! >>> Victor Rocco >>> >>> PD: Also for the correct functioning of mb2hal is necessary the patch: >>> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commit;h=4ad05d67dd11 >>> a555e72 >>> 9b750c4ed3944be044a8b >>> wich is not now in master (must be merged 2.5_branch into master in >>> order to get that). >>> >> Hi Victor (and Michael), I'm trying to understand the mb2hal code that just > went in to master. >> My question is about the file named >> 0002-A-number-of-bug-fixes-for-modbus.patch. I don't understand why that > file exists. >> I think it is meant to fix bugs in src/hal/user_comps/modbus.c, but in > patch-file format it doesn't do that. Why isn't that patch applied to the > file, if it fixes bugs? Does the patch break something else? >> >> -- >> Sebastian Kuzminsky > It is mean to fix bugs in src/hal/user_comps/modbus.c > That fixes are need by mb2hal in order to function correctly. > That patch (the additional 0002-A-...) also affects the gs2_vfd.c drive. So > I decided to NOT apply that patch (0002-A-...) directly to master to avoid > the risk of a broken gs2_fvd.c drive, because I do not have a GS2 drive to > test with. > Now i think i should be done a local copy of modbus.c and apply a local > patch to it. In this way the GS2 drive will not be affected at all. > Sorry for my lack of experience submitting contributions, I should have been > more verbose since first time. > If you want I could implement the solution of the local copy of modbus.c in > order to put an end to this problem. > > Sorry for the confusion generated. > Victor Rocco
No problem, confusion is an integral part of collaboration, thanks for helping un-confuse me ;-) I understand your motivation now and I totally support your desire to not break gs2_vfd. I appreciate that, since that's the VFD I use! However, I think the current state of the master branch is not right and should be fixed. Having a patch file in the tree is almost never the right answer - it requires the user/developer to know about it and do something by hand in order to get the benefit of the patch. Much better to make the patch worthy of being applied, and then apply it. So what's the best way to do that? In an ideal world, we would be using an upstream version of libmodbus on all our platforms, and the patch (if needed) would be sent to the upstream maintainers. Unfortunately that's not the world we live in - we've forked modbus from upstream, so we now get to maintain our own copy. I think you should figure out which parts of our software use modbus.c, and then we'll have an idea of how big a job it will be to test your changes to that file. I will gladly test your stuff on my GS2 VFD, and I bet if you put out a call for help (once you know what help is needed) other folks will step up and offer to test on the hardware they have. I'd very much prefer to just have one copy of modbus.c in our tree, and have all our drivers use that one copy. If we fork our fork of modbus.c it just multiplies our maintenance headache, and makes our system more complex. Let's try hard to keep just one copy of modbus.c. Is that enough to get started on? Please ask for help if the path forward is not clear, i'll be happy to help. -- Sebastian Kuzminsky ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
