administrators

We've just launched a new blog:

https://ioninja.com/blog/welcome-to-io-ninja-blog/

Feel free to use this forum thread for comments & discussion.

Hi Paul,

Thank you for your feedback, I really appreciate it!

We released Serial Tap Pro two months ago, and a new revision for Ethernet Tap (Ethernet Tap Pro?) is our next goal! At the very least, it should include Gigabit Ehternet support, automatic port speed selection, optional packet injection (which could be disabled at hardware level via jumpers -- just like in Serial Tap Pro), guarantee of non-disrupting the original link in case of power loss, high-precision (at least 1 microsecond) hardware timestamps, optional enclosure -- and more (hopefully, Automotive Etherent, too). We are still in the research & design stage, so there's no strict release date set -- sorry about that. As soon as we have a more definitive timeline, we will definitely post an update on this!

Hello Jason,

I've replied to this request over email, but let's cover it here, too -- in case anyone else bumps into a similar problem.

Support for Serial Tap Pro was added recently, in IO Ninja 5.8.0 -- therefore, please make sure that you are on a version higher than this. Generally speaking, you always want to be running the latest and greatest version of IO Ninja.

Also, on Windows, for Serial Tap Pro and other hardware sniffers to function correctly, the official hardware driver is required. This driver is actually nothing more than a manifest telling Windows to use the system winusb.sys for devices with our VID/PIDs (vendor and product IDs). Nevertheless, this step is essential -- without it, IO Ninja won't be able to communicate with the taps (and taps will have an exclamation mark in Windows Device Manager).

If you install IO Ninja via the "FULL" MSI installer, those drivers should be installed automatically. Otherwise (e.g., you prefer a portable .7z archive), please download drivers separately at Download -> IO Ninja Hardware Drivers; install them either (a) using dpinst64/dpinst32 or (b) through the standard Update Driver process in Device Manager.

After driver installation completes successfully, the taps in Device Manager should show no exclamation mark and use winusb.sys as a kernel-mode driver.

Greetings! The fact that IO Ninja doesn't enumerate this port on Windows means that its driver doesn't belong to the "Ports" device class:

Could you please share the .inf file for this driver? Or better yet, can you provide a download link for this virtual serial port driver so that we can play with it locally?

When on evaluation, you can use absolutely everything -- including Pipe Terminal and scripting.

However, the your script is not a valid Jancy script.

A simple echo script looks something like this:

void main() {
	char buffer[256];
	for (;;) {
		size_t size = receive(buffer, sizeof(buffer));
		transmitAll(buffer, size);
	}
}

Of course, you can modify the reply packet before transmission as you like, e.g.:

void main() {
	char buffer[256];
	for (int i;; i++) {
		size_t size = receive(buffer, sizeof(buffer));
		string_t reply = $"received block %1: '%2'"(i, string_t(buffer, size));
		transmitAll(reply);
	}
}

You can also try our stock scripts ("Load stock script" in the drop-down next to the "Open" button on the Script pane) -- they can be used as a starting point for something more meaningful.

Also, check in-app scripting tutorials here:

https://ioninja.com/doc/developer-manual/tutorials.html

Hi Jeremy,

Apologies for the delayed response.

You are 100% correct -- the hostname resolver should respect the IPv4 address when present. IPv6 should not be required when IPv4 is available.

Actually, the logic here is a bit more complex -- all socket-based plugins can optionally bind to local IPv4 or IPv6 adapters. So, when this binding is in place, the hostname resolver should choose the corresponding address family and ignore everything else.

We'll add this for the upcoming release in June. I'll share a link to the internal build after we have it done if you wish to try it before the official release.

With IO Ninja, you can monitor Modbus TCP, analyze communications, and export data for further processing.

However, there's no out-of-the-box integration with data acquisition services.

If it's the monitor-and-analyze part you are interested in, then the roadmap is as follows.

The first stage is to acquire the TCP conversation between Modbus Master and Modbus Slave. In IO Ninja, this can be done via two alternative approaches.

(a) You can capture Ethernet packets using Ethernet Tap or Pcap Sniffer (capturing via Pcap could require some trickery if the Modbus Master is not running on the same workstation as IO Ninja), then reconstruct TCP conversation by attaching TCP Flow Analyzer.

(b) But a more straightforward approach would be to use IO Ninja as a man-in-the-middle and let it forward TCP traffic between the Master and Slave using TCP Proxy. Whenever this man-in-the-middle approach is applicable (i.e., you are in control of the Master and can redirect it to IO Ninja), that should be your choice -- it's much more straightforward and reliable.

After you set everything up for reconstruction of the raw TCP conversation between Master and Slave, you attach the Modbus Analyzer to decode the raw bytes into human-readable Modbus frames.

IO Ninja log is very powerful and should be more than enough to inspect and analyze the Modbus conversation.

If you need to post-process it further, one option would be to create a Log Layer to do the job (remember, IO Ninja is scriptable!). However, for people who have never touched IO Ninja scripting before, a much more straightforward path would be to save the log as .njlog and use any scripting language of their choice to walk over it.

The .njlog file format is very simple and all the relevant data structures & constants are open-source and defined in scripts/api/log_RecordCode.jnc and scripts/api/log_RecordFile.jnc (included in IO Ninja packages).

Hope this helps; feel free to follow up with any questions!

Hello Ivan,

capture serial communication with up to 3.3mbps

3.3 Mbps is beyond the maximum baud rate supported by Serial Tap. Baud rates <= 1 Mbps are guaranteed to be reliably captured; ~2 Mbps could work in theory, but errors are possible, and I think 3 Mbps would be outright rejected by the UART controller we use in Serial Tap.

add custom protocol parsing logic

This is possible; IO Ninja supports so called "layer" plugins that can transform original logs and add decoded protocol messages. See the Modbus Analyzer for an example of such layer plugin (it's open-source and located at /scripts/plugins/Modbus/)

perform time event measurement

Events are timestamped on the PC side -- the Serial Tap reports raw bytes and status line changes, IO Ninja adds timestamps and writes them to log.

be controlled by Python with ability to get parsed data, set time markers ad get time for each events

If you need to implement custom processing in Python, you can use ioninja-hwc (https://ioninja.com/features/hardware-client.html#cli) -- capture Serial Tap events from the command line and redirect those to a file or stdout; then implement whichever custom logic you need in Python.

Unfortunately, I can't see the wiring or the mode switch position from the photo. However, on the screenshot, all the data is RX (green). Most likely, it's the usual two-wire RS485 (half-duplex), but the Modbus Analyzer is configured for full-duplex (TX Master, RX Slave) -- which is causing those parsing errors.

We have a KB article on configuring Modbus for half-duplex links:
https://ioninja.com/doc/kb/modbus_half_duplex.html

Please let me know if this works for you.

@gary-biagioni

I guess the above just goes into the scripting panes. One problem I have is how do I debug the program I write. Not sure how to be able to do that, for example, look at the contents of a variable.

You can use the good old printf debugging.

import "hexEncoding.jnc"

void main() {
	int a = 10;
	char s[] = "abcdef";
	char buf[] = 0x"01 02 03 04 05";
	
	string_t msg = $"a: %1/0x%(1;02x) s: %2 buf: %3"(a, s, encodeHexString(buf, sizeof(buf), ' '));
	// string_t msg = $"a: %d/0x%02x s: %s buf: %s"(a, a, s, encodeHexString(buf, sizeof(buf), ' ')); // same
	printf($"This will go to the system log: $msg\n");
	g_logWriter.write(log.StdRecordCode.PlainText, $"This will go to the normal log: $msg\n");
}

The system log can be viewed via Menu->View->System Log