HslCommunication: PLC libraries that stop after eight hours

All Rights Reserved, an eight-hour limit, and a VAT invoice

The first thing to establish about this project is that it is not open source, and the repository is candid about it in a way that is easy to skim past.

The CopyRight section reads (C) 2017 - 2023 Richard.Hu, All Rights Reserved. All Rights Reserved is the default copyright position and it is the opposite of an open source licence. There is no LICENSE file in the top-level listing, which is .gitattributes, .gitignore, Download/, HslCommunication2.sln, HslCommunicationDemo/, README.md and imgs/.

The Authorization section then explains how to get permission. It points to a licence page on hsltechnology.cn. It describes a trial authorisation obtained by joining a technical support VIP group, and says enterprise users can contact a WeChat number to apply for a trial certificate. And it describes commercial authorisation, which comes with source code as a gift, in four steps: sign a contract business to business, pay business to business with a VAT invoice issued, and receive dedicated software and accounts to download the latest source code and activation codes. The fourth item is separate: enterprise professional training is charged at 1000 RMB per hour for training on using and developing the controls.

So the commercial model is a B2B software sale with invoicing, and source access is the thing you are paying for rather than the default state of the code. That is a perfectly normal arrangement for an industrial library. It is also, in 2026, a genuinely surprising thing to find on a repository hosting a .NET solution, a Java port and a Python port, published simultaneously to NuGet, Maven Central and PyPI, all under a single MIT-looking badge-free commercial licence.

The eight-hour limit is the other fact to establish early, because it shapes the consuming application rather than the library. The sample code in the README calls a licence function at startup and refuses to continue if it fails:

if(!HslCommunication.Authorization.SetAuthorizationCode( "你的激活码" ))
{
    MessageBox.Show( "授权失败！当前程序只能使用8小时！" );
    return;
}

The message is that authorisation failed and the program can only be used for eight hours. So without a valid code the host application is expected to exit rather than degrade.

That is a design choice with a specific consequence: every application built on this library has to call into the authorisation API on startup and has to handle its failure, and a developer integrating it into a service or a scheduled job has to decide what eight hours means in that context. A developer working locally will hit it repeatedly. A developer who forgets the call gets a program that appears to work and then stops, which is a poor failure mode, though the eight-hour window is generous enough that it is unlikely to be mistaken for a bug.

None of this is a criticism of the vendor. It is a statement of what a reader has to know before adopting a library whose source is visible and whose terms are not the ones a GitHub repository usually implies.

The repository is the development tree, and the README says to install from NuGet

The installation section is four lines long, and the last two of them tell you not to build from the source you are looking at.

It says NuGet is for the stable version and supports online upgrade, and that using the components is best done by downloading from NuGet. Then: the project published here is likely to have not yet compiled the beta version. And then the install line, which is the Package Management Console form rather than the dotnet CLI form:

Install-Package HslCommunication

So the repository is a development tree that is ahead of, or different from, the built package, and the vendor is telling you that the artefact you should evaluate is the one on the registry.

That is an unusual and honest thing to publish in a README, and it has a direct consequence for anyone evaluating the project. You cannot read the source here and conclude that the source is what you would get. You would be reading whatever is on the development branch, which by the vendor's own statement may not be what was compiled. For a library whose whole value is a large body of protocol implementations where a subtle difference between what you read and what you get would be hard to notice, that gap matters.

The practical reading is that the repository is useful for understanding the design and the scope, and the package is what you test against. If you are evaluating HslCommunication, install the NuGet package, the Maven artefact and the PyPI package, and evaluate those.

Two other repository details support the same reading. There is a Download/ directory committed to the repository, which is where prebuilt binaries live in a project that also ships them to three package registries. And the solution file is named HslCommunication2.sln while the only release tag is v9.0.0, so the solution has carried a version-2 name through a version-9 release and six years of development. Neither is a problem on its own. Together with the beta warning, they describe a repository whose relationship to the shipped artefact is managed by the vendor rather than by a reproducible build.

There is also no way to check the correspondence yourself from what is documented. The README does not describe a build process, a versioning scheme beyond the one tag, or a way to build the solution and compare the output against the registry package. For a commercial library where source access is a paid benefit, that is a reasonable arrangement. For someone who has paid for the source and wants to verify it, the absence of a documented build is the gap that matters, and it is not addressed here.

One tag from 2020, and a copyright line that stopped in 2023

The release history of this repository is a single line, and it does not describe the state of the code.

The only release is v9.0.0, tagged 2020-02-13, and its title is 浴火重生版, which translates roughly as a reborn-from-the-ashes edition. The last push to the repository was on 2026-09-07.

So the project has one tag from February 2020 and six and a half years of commits on top of it. A major version with a codename and no subsequent tags means either that releases are cut elsewhere, which for a library published to three package registries with a commercial licence is plausible, or that the tag is simply historical and nothing is being tagged.

The copyright line compounds the picture. It reads 2017 to 2023, while the repository has been pushed as recently as September 2026. A copyright range that stops three years before the last commit is either a stale notice or a deliberate end date on the notice, and either way it does not describe the current state of the work.

The build badges point in the same direction. The C# line names Language C# 7.0 and Visual Studio 2019. C# 7.0 shipped in 2017 and Visual Studio 2019 in 2018. The Java port names JDK 1.8.0 and IntelliJ Idea 2018.4, both from 2018. The Python port names python 3.6, released in 2016. So the three language implementations are built on toolchains that are between eight and ten years old.

That is not automatically wrong. An industrial library that has to run on long-lived industrial PCs, on embedded Linux boxes and inside enterprise networks frequently cannot raise its runtime floor, because the machines it runs on are the ones that never got replaced. Pinning to .NET Framework-era C#, JDK 8 and Python 3.6 is a defensible consequence of that. But it does mean the library cannot use language features from the last decade, and it does mean a modern shop with a .NET 8 or Python 3.12 policy is adopting a component outside its own standards.

The combination of facts in this section is what an evaluator should weigh together. A commercial library, an active development branch, one six-year-old tag, a three-year-stale copyright notice, and build tooling frozen in 2018 and 2019. The code is clearly still being worked on. The question is whether the version you get from the registry matches what you would read, and the answer to that is in the NuGet, Maven Central and PyPI artefacts rather than in this repository.

Three languages, three registries, one licence

The header of this README documents the same library in three languages, and the arrangement is unusual enough to be worth describing precisely.

The .NET version is HslCommunication, on NuGet, built with C# 7.0 and Visual Studio 2019. The Java version links to a separate repository, HslCommunicationJavaDemo, and is published to Maven Central under the coordinate com.github.dathlin/HslCommunication, with badges for JDK 1.8.0 and IntelliJ Idea 2018.4. The Python version links to a third repository, HslCommunicationPython, and is on PyPI, with badges for python 3.6 and Visual Studio Code.

So three implementations, three separate repositories for the non-.NET ones, three package registries, and one commercial licence covering all of them. The GitHub user is dathlin, Richard.Hu, and the Java artefact is under a com.github.dathlin group id, which is the convention for a GitHub-hosted personal Maven repository.

The licensing implication is worth stating plainly. Nothing in the README suggests the three ports have different terms, so a reasonable reading is that the same commercial licence covers all three. That means an organisation that buys the .NET package has to establish whether the Java and Python ports are covered by the same purchase, and the answer determines whether a polyglot team is one licence or three. It is a question worth asking before committing, because the alternative is discovering it during a compliance review.

The runtime floors are the other thing to weigh, and they are visible only in the badges. JDK 1.8.0 and Python 3.6 both reached end of life years ago, and C# 7.0 as a language target means the .NET version is usable on older .NET Framework and .NET Core targets rather than on current .NET. So a team on a current runtime will be consuming a library built for an older one, which is fine for a leaf dependency and awkward for a core one.

The three-domain arrangement is a small curiosity in the same area. The repository's declared homepage is hslcommunication.cn. The authorisation link and the company site are on hsltechnology.cn, a different domain. The API documentation is at api.hslcommunication.cn, a third host. So a reader looking for terms lands on a different company's site from the one the repository is named after, and the API reference is on a subdomain of the repository's own domain. All three are plain HTTP in the README, which for a site that hosts licence terms and downloads is worth noting on its own.

What the library actually covers, which is the reason to buy it

The functional description is where the value is, and it is written in the slightly breathless register common to Chinese industrial software marketing. Setting that aside, the coverage is genuinely broad and is the substantive thing to evaluate.

The description names Mitsubishi PLC communications, Siemens PLC communications, OMRON PLC communications and Modbus communications, and the repository topics add Allen-Bradley, Melsec and Panasonic. Redis, MQTT and WebSocket are also named in the description, so the library is not limited to talking to PLCs; it also provides the transport for getting that data off the device.

The architectural claim is that the same implementation is available in multiple languages so that a team is not tied to one platform, and that the .NET version is the most capable. That maps onto the three ports described above, with the .NET one being primary.

The scope is broader than protocol drivers. The README lists a logging function, a flow number generation function, an email sending function and a Fourier transform function, and says more common industrial features will be integrated in future. A Fourier transform in a PLC library is a strange neighbour to a Modbus driver, and it suggests the library is positioned as a general industrial toolbox rather than a narrowly scoped protocol layer. For a buyer, that is a double-edged property: one dependency covering many needs, or one dependency whose maintenance and licensing you now own for features you do not use.

The intended systems are described next. Whatever your acquisition system, usually a Windows computer, an embedded system or a Linux-based box, the library can achieve random transmission of data. And it covers client-server, browser-based, and a hybrid model the README names as an integrated desktop client, browser and Android, abbreviated in the text as C-B-S-A.

The listed use cases are the ones a buyer can check against its own requirements: real-time monitoring, production reporting, automated scheduling, process parameter history tracking, software built on accumulated machine experience, and a full-featured manufacturing execution system.

There is also a business model argument in the README, which is unusual and worth reading because it tells you who the vendor expects to be the customer. The traditional model is to buy off-the-shelf industrial software, host software and MES, and ignore building your own. For industry-standard software such as ERP and financial systems you can buy directly, but host software and MES needs differ so much between enterprises that there is no common scenario, and the result is spending a lot of money doing small things. The model proposed instead is two-sided: production enterprises build an enterprise MES on top of HSL as the data warehouse and business logic core, while equipment suppliers build host software on top of HSL and distribute data to the customer's MES.

That is a platform strategy rather than a library sale, and it explains the breadth of the feature list, the B2B contract process, the paid source access and the training offering. An evaluator should read the README's last section as the commercial pitch and the protocol list as the product, because they are aimed at different readers.

Editorial conclusion

Use HslCommunication if you need to read and write PLC data from a .NET, Java or Python application and you are prepared to buy a commercial licence, because the protocol coverage across Mitsubishi, Siemens, OMRON, Modbus, Allen-Bradley, Panasonic and Melsec is the reason to buy it rather than a reason to hesitate. Do not adopt it on the assumption that a library on GitHub, NuGet, Maven Central and PyPI is open source: there is no LICENSE file, the copyright line says All Rights Reserved, and the source access itself is a paid benefit of a contract. Do not build your own product on the repository rather than the package, because the README states the code published here is likely not the compiled beta version and directs you to NuGet for the stable one. Verify five things. Whether your organisation can obtain a licence through a business-to-business contract with a VAT invoice, since that is the documented route. Whether the eight-hour limit is workable for your development loop, because every consuming application has to wire in the licence call at startup. Which of the three language ports you need and what its toolchain floor is, since the badges name C# 7.0, JDK 1.8, IntelliJ 2018.4 and Python 3.6. Whether the version on the registry matches the one you evaluated, given the only release tag is v9.0.0 from 2020-02-13 and the source has moved since. And whether paid training at the stated rate is part of your budget, because it is listed as a separate commercial item. The deciding fact is that the licensing is unambiguous once you read it, and the only real risk here is a reader who assumed the hosting meant open source.

Frequently asked questions

Official sources

1. dathlin/HslCommunication on GitHub
2. Issues
3. Project website
4. README
5. Releases