> -----Mensaje original----- > De: Sebastian Kuzminsky [mailto:s...@highlab.com] Enviado el: > Miércoles, 24 de Octubre de 2012 04:07 p.m. > Para: EMC developers > Asunto: Re: [Emc-developers] I would like to contribute a "modbus to hal" component, AKA mb2hal. > > > 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
Thanks you for the advice. I did the homework. There are only 4 programs that uses modbus communications: 1) classicladder 2) gs2_vfd 3) vfs11_vfd 4) mb2hal. 1) classicladder have their own implementation of modbus. So will NOT be affected by the patch. 2) gs2_vfd uses the modbus functions 0x06 preset_single_register and 0x03 read_holding_registers. So will NOT be affected by the patch, that fix functions 0x0F force_multiple_coils and 0x02 read_imput_status. 3) vfs11_vfd uses libmodbus3. So will NOT be affected by the patch. 4) mb2hal needs the patch. I am confident that you could apply the patch (0002-A-.....) to master WITHOUT problems. Just to be sure, i will be glad if you do some test with your own GS2 drive. Thanks you in advance. Victor. ------------------------------------------------------------------------------ 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 Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
