Currently, IAS (in-app-script) can only control the underlying session via:

• connect()
• disconnect()
• transmit(p, size)

Fine-tuning of the sessions configuration is currently not possible from IAS. But we plan to add this capability in the near future.

Each session class will export a public IAS interface (e.g., a serial session will have properties to query and control baud rate, parity, status lines, etc.) Then, IAS should be able to access this interface via a global constant g_session (or something like that).

Please read the introduction to the new licensing model here: https://ioninja.com/capabilities-intro.html

In particular, the section "Have a License?" outlines how to reuse old licenses in IO Ninja 5.

Also, Serial Taps (and all other IO Ninja hardware taps) do not require any paid capabilities and should work just like before, even with fewer restrictions. With IO Ninja 3, to use a Serial Tap, one had to possess a license. Now, it's not required -- for example, you can freely share Serial Taps with your friends.

Sure. The basic idea is to listen for new log records and update your variables holding the state of RTS/CTS lines accordingly. You would need SerialLogRecordCode.PortOpened to get the initial line state on port open, SerialLogRecordCode.RtsChanged to track RTS changes, and SerialLogRecordCode.StatusLineChanged to track CTS changes.

In the sample below, I simply print the states of those lines to the session system log (Menu -> View -> System Log). Feel free to change it according to the requirements of your script.

import "io_base.jncx"
import "io_Serial.jnc"
import "Serial/SerialLogRecordCode.jnc"

bool g_rts;
bool g_cts;

void onLogRecord(
	uint64_t timestamp,
	uint64_t recordCode,
	void const* p,
	size_t size
) {
	switch (recordCode) {
	case SerialLogRecordCode.PortOpened:
		SerialOpenParams const* params = (SerialOpenParams const*)p;
		g_rts = params.m_rts;
		g_cts = (params.m_statusLines & io.SerialStatusLines.Cts) != 0;
		printf("Initial RTS: %d CTS: %d\n", g_rts, g_cts);
		break;

	case SerialLogRecordCode.RtsChanged:
		g_rts = *(bool const*) p;
		printf("RTS changed: %d\n", g_rts);
		break;

	case SerialLogRecordCode.StatusLineChanged:
		SerialStatusLineChangedParams const* params = (SerialStatusLineChangedParams const*)p;
		if (params.m_mask & io.SerialStatusLines.Cts) {
			g_cts = (params.m_lines & io.SerialStatusLines.Cts) != 0;
			printf("CTS changed: %d\n", g_cts);
		}
		
		break;
	}
}

Could you please share your wiring diagram? Or a photo of how you connect the tap?

For RS485 half-duplex (two-wire), you need to connect either the (RX+/RX-) pair or the (TX+/TX-) pair. The only difference it's going to make is how the data will be called in the IO Ninja log -- RX or TX. For RS485 full-duplex (four-wire) -- which is far less common -- you need to connect both (RX+/RX-) and (TX+/TX-). But you definitely don't need two taps to sniff a single serial link.

Oh, so you are using a Serial Tap for IO Ninja; not a generic dual-COM serial tap.

Then you need to use a dedicated "Serial Tap" plugin (not "Generic Serial Tap").

Generic serial tap reads from two ports at the same time -- one port obtains RX, CTS, DSR; the second one obtains TX, DTR, RTS. Oftentimes, only TX and RX are required -- it simplifies the wiring. There are various over-the-counter dual-COM taps available; you can easily solder (or build on a breadboard) your own one, too.

The log error message says "ports A and B" while the toolbar refers to those ports as "DTE" and "DCE". This is confusing, I agree. We will change the port names in the log to "DTE" and "DCE" for consistency.

Hopefully 1 last questions - you are calculating the CRCs and reporting whether they are accurate/correct - do you just run through a bunch of different CRC algorithms at the start of a capture to try and work out which is the correct one ?

Modbus RTU is using CRC16 (ANSI) with the seed value of 0xffff. You can see the Modbus checksum of any data block in the "Checksum calculator" of the Information pane on the right. Select a range of data, and it will be instantly calculated.

The code should look something like this:

uint16_t modbusChecksum = crc16_ansi(p, size, 0xffff);

The implementation of crc16_ansi is in scripts/common/crc16.jnc

Perfect thanks !!! Now i am getting a good decode of what is going on

Glad to hear it works now!

Is there anyway to export the Hex Strings (without decode) into a text file

Yes, you can export your log as a text file (Menu -> File -> Save Log As...) at any time.

I often find it easier when decoding unknown devices (in terms of registers) to look for patterns and things that are constantly changing to give a hint as to what the data could represent.

If you want just the pure data without annotations added by Modbus Analyzer -- remove the Modbus Analyzer layer, and you will get back to the original log. Modbus Analyzer (as well as other protocol analyzers) does not destroy the original log, so it's totally reversible.

Another option to get to the raw data is to post-process the original .njlog file. It will be more efficient than parsing a hex view inside a text file. The .njlog file format is open-source (log file structure definitions are in scripts/api/log_RecordFile.jnc), so you can use any programming language of your choice.

An example of decoding *.njlog files can be found in scripts/plugins/ReplayLog/ReplayLogLayer.jnc, function ReplayLogLayer.readLoop(). This plugin reads a log and "replays" TX or RX data with respect to inter-packet delays. It's probably not exactly what you want, but it should give an idea of how to "walk" across a raw .njlog file to process the captured data.

Your decode window etc is brilliant i must say though !!
Great product

Thank you! We work hard to make our product as versatile and convenient as possible, so I really do appreciate such feedback

I assume as i am just listening i would tap into the RX+/RX- lines - whereas if i wanted to inject i would tap into the TX+/TX- instead ?

Serial Tap is a read-only sniffer device; it can't drive lines. TX+/TX- connectors are for the full-duplex RS485 links, aka 4-line RS485. It's not as common as half-duplex RS485, though.

BTW it's also possible to connect the D+/D- pair to TX+/TX- connectors (instead of RX+/RX-). The only difference it will make is the icon and color of captured data in the log (green for RX, blue for TX).

Framing errors are a common symptom of (a) wrong wiring or (b) wrong serial parameters (most likely, baud rate or parity). From your description, it sounds like you "inserted" your Serial Tap in-between the two nodes.

First, be sure to use the terminal block on the top. The DB9 connectors on the sides are not going to work with RS485 -- they are only for RS232 (as can be seen on this block diagram).

Next, another common misconception is "breaking" the original lines and inserting the Serial Tap in-between as shown on the left side of the picture below:

For sniffing half-duplex RS485 links, use the wiring shown on the right (also, if there is a GND line besides D+/D-, it helps to connect it as well).

Once you receive a sensible-looking stream of raw data (with no or maybe occasional FRAMING errors) you can try attaching the Modbus Analyzer. Keypoints of configuring the Modbus Analyzer for half-duplex RS485 links are outlined in this KB article.

Hope this helps!