administrators

Are those little icons on the snapshot indicates the type of connection besides it is a pipe? (Socket, shared memory, message queue)

Pipe Monitor shows named and anonymous pipes only.

Anonymous pipe opens will be marked as (unnamed). If you run a Win32 code to create anonymous pipes such as:

	HANDLE hReadPipe;
	HANDLE hWritePipe;
	dword_t actualSize;
	char data[] = "abcdefghi";
	char buffer[1024];

	::CreatePipe(&hReadPipe, &hWritePipe, NULL, 0);

	::WriteFile(hWritePipe, data, sizeof(data), &actualSize, NULL);
	::ReadFile(hReadPipe, buffer, sizeof(buffer), &actualSize, NULL);

	::CloseHandle(hReadPipe);
	::CloseHandle(hWritePipe);

You should see something like:

The screenshot failed to upload; could you try again, please?

Regarding the IPC method, well, the Pipe Monitor shows communications over named and anonymous pipes. To see if a particular read or write is issued over an anonymous or named pipe (and the name of the pipe), you have to follow the log up all the way to the pipe open operation for this particular file ID; there you'll see the file name and the role (client or server).

Yes, you can use Serial Tap to monitor RS422 communications. Use the RS485 portion of the terminal block to connect your TX+/- and RX+/- lines.

Hello,

ModbusRtuWritePacket is from the legacy Modbus packet template library; it doesn't support multiple values per packet. The new Modbus plugin uses structures defined in scripts/protocols/io_Modbus.jnc. If you need to do it programmatically, just assemble your packet structure from necessary chunks (ADU hdr, PDU hdr, function-specific params, values, CRC). Important -- be sure to add pragma(Alignment, 1) as to avoid unintended struct paddings!

After the packet structure is defined, fill in the fields and calculate the checksum. Modbus RTU checksum is CRC16 ANSI (with init 0xffff) of the whole frame excluding the checksum itself.

The full script listing is below:

import "io_Modbus.jnc"

void main() {
	enum {
		DeviceAddress   = 1,
		RegisterAddress = 0xA000,
		RegisterCount   = 2,
	}

	pragma(Alignment, 1)
	struct MyPacket:
		io.ModbusRtuAduHdr,
		io.ModbusPduHdr,
		io.ModbusWriteMultipleParams {

		bigendian uint16_t m_registers[RegisterCount];
		uint16_t m_crc;
	}

	MyPacket packet;
	packet.m_deviceAddress = DeviceAddress;
	packet.m_func = io.ModbusFunc.WriteMultipleRegisters;
	packet.m_address = RegisterAddress;
	packet.m_count = RegisterCount;
	packet.m_size = sizeof(packet.m_registers);
	packet.m_registers[0] = 123;
	packet.m_registers[1] = 456;
	// ...
	packet.m_crc = crc16_ansi(packet, offsetof(packet.m_crc), -1);

	transmit(packet, sizeof(packet));
}

Hello Jose,

Sure, no rush with the feedback -- please take your time.

And thank you so much! Wishing you a Merry Christmas and a Happy New Year as well! Enjoy your winter holidays!

Here's an internal build of IO Ninja for arm64:

https://tibbo.com/downloads/archive/ioninja/.internal/prerelease/ioninja-5.7.1-c-linux-arm64.tar.xz

The ioninja-hwc introduces two new parameters:

--split-size <bytes> and --split-time <seconds>

Both options can be used together; in this case, the splitting will occur based on whichever condition is met first. Both options support reasonable suffixes, e.g., --split-size=10M, --split-time=6h, etc.

Let me know if this works for you!

If this is something you could add "for free" to your new development, great! If not, well, I think that this is no a common case, in fact, I found it very weird (but "real" indeed).

Yes, it comes for free, so we'll have a setting for that!

if possible/feasible/reasonable, consider the options of splitting by size (eg. each "n" MB) and by time (eg. each "t" minutes). It is just an idea... perhaps it seems more logic just consider the size, but -eg. for my case- it is more convenient to have captures of info more or less time aligned (eg. daily aligned... in fact, I am currently splitting them each 6 hours)

Good point! Let's have settings for both!

consider the option of being "transparent" when power-off...

Oh yes, I agree! This is absolutely one of the must-have features for the next generation of Ethernet Tap. Disconnecting power from the tap should not disrupt the existing link.

Well, then have to add help tooltips to every other setting, too, for consistency... Which could be the right thing to do, actually

In this particular case, however, I'm kinda inclined to simplify and drop this setting altogether (use hex-line-size / 2 for this special dual-hex-view mode).