Our Net2 software has been updated to include support for the latest version of Windows. With Net2 v6.6 SR1, you can now manage your Net2 system on a PC running Microsoft operating system, Windows 11. The software update is available for Paxton installers to download now.
Net2 is our networked access control solution, designed to make the management of any building very simple. It can be administered using one or more PCs and can be monitored and managed from a central location. It is a complete solution that encompasses wireless and door entry.
In each case, the compatibility is conditional on up to date service packs and updates being applied. Server operating systems are compatible, but will probably require IT expertise unavailable from our support team in order to complete a working installation. This particularly applies to special versions of operating systems.
Anti-virus or spyware programs may interfere with the installation of any software, including Net2. We recommend McAfee which seems to give the fewest problems. In the event of difficulties during installation of Net2, we advise that the anti-virus software should be disabled. Should difficulties persist once the anti-virus software is re-enabled, the person responsible for supporting the anti-virus software should be consulted. Our support team will be unable to offer advice in this event.
Microsoft do not recommend installing SQL on a Domain Controller due to security risks using SQL 2008/2012 on a Domain Controller, for this reason we have prevented the install of Net2 on Domain Controllers from v4.28 onwards.
As new features are developed and bugs are fixed, we release updates to our software. This can involve updates to the database, including updating to a new version. Historically, we have migrated from Access 97 to Access 2000, to MSDE, to SQL 2005, 2008 and then 2012. Future developments may require we migrate to a different database altogether. This would not be possible if the Net2 database was hosted externally.
Where devices have an Ethernet network port, (e.g. a TCP/IP RS485 interface, or a Net2 I/O board) the device will be compatible with IEEE802.3 Ethernet infrastructures supporting 10BaseT at 10Mbps using the IPV4 network protocol.
IP data traffic between the user interface software and the server software (where client server mode is used) and between the Server software and the I/O boards use ports in the range 6474 to 6485 inclusive. When using a TCP/IP RS485 adaptor, ports 10001 and 30718 are used. A combination of TCP and UDP communications are in use. This should be taken into account in routers where port filtering or forwarding are employed.
Implementing the correct level of network security on your site is strongly encouraged. It is the responsibility of the user to use the appropriate level of security for your site. Paxton recommends the following IT security precautions for your reference. Please click here for more information.
We have a telephone support team available to advise on the installation of Net2 software and its use. They are able to take enquiries from installers before or after commissioning a system, and from those using the system.
Our support team is trained in the use of the software and understand the basic procedures for installing it on the recommended operating systems. Almost all installations are straightforward and require no advice or help from us. However, where unusual problems do occur, it may be necessary to revert to more experienced members of our support team or development team for advice. This may require a number of contacts by telephone over several days.
Advice given by our support team may be restricted to installation and operation of the Net2 system and software only. Any other advice given or discussions relating to PC hardware, operating systems, network infrastructure or any system or software not provided by Paxton Access are informal, without obligation and are not intended as a replacement for appropriate professional skills which should be provided by the installer. Our Terms and Conditions of Sale also apply.
We are just wrapping up correcting a host of troubles we had with our network that seem to have been related to incorrect firmware and a bad POE injector. The system consists of an Obsession II single processor running 5.1.0, three 4 Port Nodes, 4 2 Port Nodes, a Video Node, and a dedicated PC for NCE.
We were advised to run the Version Detect and Upgrade Utility from NCE 4.0.3 to roll back the firmware on all of the nodes, which we did. Currently all of the Nodes show a "Net Version" of 4.0.x (the exact version varies from node to node for some reason), but all of the 2 Ports show an "App Version" of 4.1.x (again exact version varies). What exactly is the difference between "Net Version" and "App Version"?
Also, I would like help parsing an error message we received at one point when we had devices falling over left and right. If I remember correctly it was: [memory address] (tNetTask): arp info overwirtten for [second memory address] by [MAC address]. I apologize, I know it would be more helpful if I had the specific memory addresses and MAC addresses. The first time this happened it was two devices (a four port and the video node) each trying to overwrite the same memory address. Based on my limited understanding of ARP tables, my guess was they were each trying to claim the same IP address, though this was not how they were configured. While this was repeatedly happening the system essentially ground to a halt. After we had corrected the firmware on all the nodes and replaced the bad POE injector, we got the same address once more, again the video node, but it only happened once and we didn't see any loss of function or communication between any of the devices. It appears to be a non-issue, but if someone from ETC could more clearly elaborate on what's happening when that system message appears I would feel much better. Thank you.
My gut reaction after doing a quick read is that you indeed have two systems IP conflicting. Probably (because I've done this before) you have a DHCP server running somewhere while you are also trying to assign the IPs manually, and those two pools are conflicting. Once the DHCP server is removed, the system fixes itself. Sometimes its easy to forget that NCE will run its own DHCP operation if you don't turn it off. Also, depending on other network gear running in the system, one of them could be running DHCP, or if there is a consumer router in the system, it could be messing with the ARP tables if UPnP is running or some other "automatic" routing system.
In response to Derek's comment, NCE is the only device in the system with a DHCP server, and the address server was not on at the time of the error. Actually, NCE wasn't running, it's only opened when configuring the input node (50.201).
I am using .NET4.0, but for compatability reasons, I'd like to compile to a .NET2.0 dll from c#. There should be no .NET4.0 specific functionality used in the script, so it should run fine in a .NET2.0 environment. Is there some commandline syntax on the csc that I can specify a version number with?
If you build with MSBuild (which of course includes from within VS) then you can specify the target framework version from the project properties dialog. However, if you build manually it seems there is no surefire way to express that restriction.
Set the target framework to 2.0 in the project's properties. In case you are using features like LINQ that are not present on the 2.0 framework, this approach won't work. If you need full compatibility with 2.0 framework, you should write your code for the 2.0 and then compile targeting the 4.0 later if you need.
A few months ago we released a preview of the Text Classification API. As the name implies, this API enables you to train custom models that classify raw text data. It does so by integrating a TorchSharp implementation of NAS-BERT into ML.NET. Using a pre-trained version of this model, the Text Classification API uses your data to fine-tune the model.
This scenario supports local training on both CPU and GPU. For GPUs you need a CUDA-compatible GPU and we recommend at least 6 GB of dedicated memory. For more details on setting up your GPU, see the ML.NET GPU guide.
To enable Natural Language Processing scenarios like Text Classification and Sentence Similarity, we needed a way to process text data. This is often done using tokenization techniques. We implemented a tokenizer for the English Roberta model which uses the Byte-Pair Encoding algorithm to satisfy the NAS-BERT model requirements.
We then decided to publish the tokenization APIs inside of ML.NET in the Microsoft.ML.Tokenizers NuGet package. You can use the APIs provided in that package to import custom vocabularies and use the BPE tokenizer to process text data.
The encoded results provide information such as Ids which map to the index of that word in the vocabulary file as well as offsets which indicate the positions where each of the tokens starts and ends. For example:
This year we worked on bringing that implementation of AutoML to the dotnet/machinelearning repo and adding more capabilities to provide great code-first experiences for machine learning beginners as well as experienced users.
Over the next year, we plan to continue improving the AutoML API to enable new scenarios and customizations to simplify machine learning workflows for both beginners and experience users. As we refine these experiences we plan to bring them to the Model Builder and ML.NET CLI tools.
64591212e2