Hi Lukasz, coming back from a little holiday ... What I found was this "SocketCAN" interface, which seems to be intended to be a standard API for multiple CAN hardware interfaces: https://en.wikipedia.org/wiki/SocketCAN There seems to be a java library, making that accessible via JNI (Haven't tested it): https://github.com/entropia/libsocket-can-java It's MIT licensed, which is a category A license, so we should be safe using it.
This however would not work on windows machines (and I don't know if Macs would work) Another option are "Can-To-TCP" converters or USB to CAN converters. There seems to be an open-source/hardware project called "canable" https://canable.io/ Is a USB device that pops up as a serial device (Would certainly make building a Netty driver simple as we already have a Serial endpoint, for the SocetCAN we would need to build a new one and I haven’t even finished the Raw-Socket one. The Can-To-IP/TCP converters also would have the benefit of not needing a special Netty endpoint. However they all look a lot more complex. Instead of a small embeddable mini-board they seem to be real devices. I think when connecting to a CAN bus which controls for example Robot Drives and CNC steppers, I think the transfer rates for the serial might be limited ... would be interesting to see what all these solutions produce as output. I mean they can all read standard CAN telegrams, but it doesn't tell us what the output is. If it's just the unprocessed data from the can bus, we could create a "can-protocol" and several "can-driver" modules. Chris Am 05.12.18, 13:44 schrieb "Łukasz Dywicki" <[email protected]>: err, to clarify myself. I wrote: I know there is ser2net and socat, but latencies introduced by bridging might not be as effective as you would expect. where I meant: I know there is ser2net and socat, but latencies introduced by bridging might make testing less effective than you would expect. Cheers, Lukasz On 05.12.2018 13:11, Łukasz Dywicki wrote: > Hey Christofer, > I'm fine with VPN access. I had a chance to talk with people who > deployed "my" openhab bacnet integration with several big swegon units > (9000 m3/h each) and gave it a try. I can agree with them to collect > PCAPs, I could also ask other users who contacted me to get sample traffic. > This approach will definitely work with bacnet/ip, but with VPN access > we can't reliably test serial interfaces. I know there is ser2net and > socat, but latencies introduced by bridging might not be as effective as > you would expect. > More over VPN have one important side effect. I can't show "real" thing > being controlled with software while I meet people. Small devices with > serial interfaces have its advantage - you can take them with you at > fare, show that they actually work with your program and your software > can communicate with them. > Just think of impression which could be made with bidirectional > communication between two and more protocols with OPC-UA on top of > everything. > I think such things would speak nicely to automation guys at trade shows. > > Ps. You can call me Lukasz and Luke, all these variants are fine! > > Cheers, > Lukasz > -- > Apache Karaf committer & PMC member > Founder of http://connectorio.com > > On 05.12.2018 10:46, Christofer Dutz wrote: >> Hi Lukasz (Hope you forgive me for not using that L with the strike through ... I just don't know where to find it) >> >> Happy you're willing to help out with this :-) >> >> Regarding hardware ... I think we might have a different option here. I know a big company near Frankfurt asked about BacNet support ... I think we might be able to convince them to provide us with a reasonably big device (so we can test all different sorts of things). If they do, we would add the device to our IoT Lab network here in the FFM codecentric office. This way everyone interested could access it through our IoT Lab VPN ... would that be an option for you? As I have a meeting with them this afternoon, I'll definitely ask them. >> >> Regarding the drivers ... I think the way we currently implement most of them, should make it easy to implement a BacNET driver or a CAN driver without having to stick to one hardware platform (for the CAN bus driver). The Protocol should be the same for all hardware implementations, so I assume we could implement a CAN Protocol layer and provide multiple implementations of driver modules using the CAN protocol layer. I would be more than happy to help you get started with this (Might even write that down as I think this would be a good thing to read for others interested) >> >> Chris >> >> >> >> Am 05.12.18, 01:31 schrieb "Łukasz Dywicki" <[email protected]>: >> >> Hey Guys, >> I come over plc4x already few times, had chat with Christofer as I peek >> into "industry" side of software from time to time and I am interested >> in evolution of project, both as contributor (if I have time & budget) >> and possible user. >> >> A while ago I authored bacnet integration for openhab (actually decoded >> bacnet4j magic) which is used in several places. I would love to move >> that part forward as bacnet is widely used in bigger buildings. >> Obviously because bacnet4j license is not compatible with ASLv2 nor EPL >> I can't contribute my work back to Eclipse Smarthome nor OpenHab project >> which makes maintenance of bacnet integration a real burden. >> I see commercial spaces as another corner of "industrial" stuff since >> most of them have lots of equipment which is in some cases also used in >> manufacturing. >> >> Coming back to the point, after going over specs and learning how >> advanced bacnet could be, finding that most of unit tests for bacnet4j >> is left for historical, but not practical reasons, I come to conclusion >> - hey maybe it would be good idea to create a naive and simplistic >> bacnet api, just to have a rough read/write support. Then we could see >> if it will "catch" and have any traction. So far I completed easiest >> part - creating interfaces without actually touching a serial/udp codec. :) >> I know we I can get pcaps, I can even use my home ventilation unit to >> collect some, but I lack a bacnet mstp interface big time. I can't test >> bacnet4j nor even check if my code works with it. >> Since there is a bunch of people on this mailing list who most likely do >> or did some work with industrial stuff maybe, by some chance, you are >> able to point some cheap equipment for bac ms/tp testing. Here I mean >> something basic even with one property, a switch or actuator which >> doesn't cost 200€. The computer side I should be able to cover with >> standard RS485/USB adapter. >> I remember that in one of materials related to plc4x there was >> information about some firm (or someone) who contributed test equipment >> to project. Maybe it would be good idea to drop an information about >> cheap lab equipment on the webpage, which will let people to experiment. >> As long as costs are close to 50€/$60 (lets call it raspberry barrier) >> there is a chance that people will play with things. We all know that >> its not a industry grade hardware, but that's not what we require for >> most of time to test communication. >> >> Since I already mentioned openhab, I would like also to ask about one >> more standard/protocol which I was asked about in context of building >> automation - which is CANbus. I found it today on one of pictures on >> plc4j related to S7 - are there any plans getting CAN supported? For >> quite long time I presumed that CAN is car specific thing, but >> apparently I was wrong and it is used "in the field" as well. >> Having a cheap device which speaks CAN and pluggability to computer is >> usually first step to get things done. It might be also last one (as we >> are just humans and we often are short with time for fun projects), but >> having it is better than not having it. :-) Hope you get the point. >> >> From my own side I might be able to contribute later this year/early >> next year a sample lab setup for wmbus/mbus. These two are quite popular >> in Europe for media consumption and have plenty of vendors who use it >> together following DLMS/OMS spec. >> >> Kind regards, >> Łukasz Dywicki >> -- >> Apache Karaf committer & PMC member >> Founder of http://connectorio.com >> >>
