Hey Stephen, It really depends how you copied the repository. Have a look on output of "git remote -v" command. For me its: connectorio g...@github.com:ConnectorIO/plc4x.git (fetch) connectorio g...@github.com:ConnectorIO/plc4x.git (push) origin g...@github.com:apache/plc4x.git (fetch) origin g...@github.com:apache/plc4x.git (push) Each time when I do git fetch or pull it defaults to "origin". If your origin points your github fork then you might not see all branches immediately.
I believe that quickest and dirtiest way is to do: git remote add plc4x g...@github.com:apache/plc4x.git git fetch plc4x git checkout feature/modbusrtu Best, Łukasz On 18.08.2021 14:56, Stephen Snow wrote: > Hi Ben, > I forked the repo, actually had it forked for snapshot 0.7.0 so just > had to merge the commits from the repo. > > On Wed, 2021-08-18 at 07:12 +1000, Ben Hutcheson wrote: >> Hi Stephen, >> >> I have pushed support for RTU to the branch feature/modbusrtu, it >> seems to >> work. I've only used RTU over TCP using the connection string >> modbus-rtu:tcp://127.0.0.1:502. There is also a few things to update >> docs, >> test and refactoring. >> >> Until it gets merged into the develop branch it won't appear in the >> 0.9.0-SNAPSHOT so you'll have to build the feature/modbusrtu branch >> using > > I couldn't find that branch listed. I see 48 branches in my fork. > >> maven. Once you have built it then it will get stored in your maven >> repository cache as the 0.9.0-SNAPSHOT >> >> As you are looking at contributing you should take a look at >> https://plc4x.apache.org/developers/contributing.html >> This gives you an overview of how to fork the main repository and >> keep it >> up to date. >> >> Once you have it forked then you should be able to update your copy >> and >> push the changes to your fork. This should then request you to create >> a PR >> (You can change it to push to the feature/modbusrtu branch on the >> main >> repository) which we can review. A simple change if you want to test >> it >> would be to add a Modbus RTU ascii doc to the folder >> src/site/asciidoc/users/protocols folder based on the existing Modbus >> TCP >> page. >> >> There's plenty of people activate that are generally more than happy >> to >> help if you have any questions >> >> Ben >> >> > Any thoughts? > Stephen > >> On Tue, Aug 17, 2021 at 10:45 PM Stephen Snow <s40...@gmail.com> >> wrote: >> >>> Hi Ben, >>> >>> On Tue, 2021-08-17 at 06:50 +1000, Ben Hutcheson wrote: >>>> Hi Stephen, >>>> >>>> Thank you for the offer and if it's ok I'll certainly take you up >>>> on >>>> it. >>>> >>> Sure, what snapshot should I point maven to? Currently I have 0.8.0 >>> that I was playing with a bit yesterday. >>> >>>> Next week I'll be starting a new job so I won't be contributing >>>> for a >>>> while, However I'll try and get something up and running this >>>> week. >>>> If you >>>> are able to test it and/or take over the implementation from >>>> there it >>>> would >>>> be great. >>> Should I fork the repo? Where do I look for the directions on PR's >>> etc...? >>> >>> Stephen >>> >>>> >>>> Ben >>>> >>>> On Tue, Aug 17, 2021 at 4:25 AM Stephen Snow <s40...@gmail.com> >>>> wrote: >>>> >>>>> I'd be more than willing to setup some equipment for a lab to >>>>> test >>>>> with. Readily available to me are a couple of Omron CP1-H CPU's >>>>> and >>>>> a >>>>> Red Lion G3800C (which is outdated, but communicates with >>>>> everything >>>>> ootb), plus I can easily get some Modicon stuff as well. The >>>>> Omrons >>>>> are >>>>> fitted with serial ports capable of communicating RS-485 in >>>>> modbus >>>>> RTU, >>>>> and the RLC HMI can talk Modbus TCP as well, so that is without >>>>> laying >>>>> my hands on some Modicon equipment. >>>>> >>>>> Let me know, and I can start pretty much as soon as I clear >>>>> space >>>>> on my >>>>> lab bench for the setup. >>>>> >>>>> Stephen >>>>> >>>>> >>>>> On Mon, 2021-08-16 at 11:44 +0000, Christofer Dutz wrote: >>>>>> Hi Stephen, >>>>>> >>>>>> it's not that we're dropping anything ... it's just that we >>>>>> haven't >>>>>> put any work into creating such a driver. Some day, if >>>>>> someone >>>>>> stumbles over PLC4X with the need to use ASCII, we might >>>>>> implement it >>>>>> for them (Mabe as a paid-gig or not). >>>>>> >>>>>> In the inital days of PLC4X I invested a huge amount of time >>>>>> into >>>>>> thinking what the industry could need ... I switched to the >>>>>> way >>>>>> more >>>>>> healthy mode of implementing was is actually needed and when >>>>>> it's >>>>>> needed. >>>>>> >>>>>> But I agree ... Modbus TCP, Modbus RTU (over RS or TCP) are >>>>>> definitely flavors we should be supporting. >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>>> -----Ursprüngliche Nachricht----- >>>>>> Von: Stephen Snow <s40...@gmail.com> >>>>>> Gesendet: Montag, 16. August 2021 13:39 >>>>>> An: dev@plc4x.apache.org >>>>>> Betreff: Re: Modbus RTU >>>>>> >>>>>> So I use modbus in all it's flavours, including modbusRTU and >>>>>> Modbus >>>>>> TCP. And the newer flavours Modicon is using now. Modbus RTU >>>>>> is >>>>>> definitely in heavy use on industrial equipment I encounter. >>>>>> It >>>>>> is >>>>>> commonly a drive networking choice, and a HMI networking >>>>>> choice. >>>>>> So, >>>>>> depending on what is using it ASCII is likely needed too. The >>>>>> one >>>>>> thing you don't want to do is drop ASCII. >>>>>> >>>>>> Regards, >>>>>> Stephen >>>>>> >>>>>> >>>>>> On Sun, 2021-08-15 at 23:48 +0200, Niclas Hedhman wrote: >>>>>>> On 2021-08-15 22:40, Łukasz Dywicki wrote: >>>>>>>> Then each driver flavor of modbus (rtu, ascii, tcp) would >>>>>>>> simply >>>>>>>> need to wrap and unwrap structures coming from an >>>>>>>> transport. >>>>>>> >>>>>>> seeing the ascii variant since the 1980s or early 1990s. >>>>>>> IIUIC, >>>>>>> it >>>>>>> was >>>>>>> mostly used for hand terminals, and not to connect to >>>>>>> computers. >>>>>>> So I wouldn't spend time on that, unless nothing else is >>>>>>> around. >>>>>>> >>>>>>> I haven't checked the mspec in details, but I suspect it is >>>>>>> close >>>>>>> to >>>>>>> fair amount of equipment has extensions that are not in the >>>>>>> specification (well, at least last time I read it about 20 >>>>>>> years >>>>>>> ago), >>>>>>> namely floating point numbers and 32/64-bit integers. It >>>>>>> would >>>>>>> be >>>>>>> neat >>>>>>> to support that... >>>>>>> >>>>>>> Unfortunately, I don't have cycles to help out with it. >>>>>>> >>>>>>> Cheers >>>>>>> Niclas >>>>>> >>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > >
