Hey DHagan,
I actually saved the library for previous (2011) and uploaded it to the discussion page. There may be some unknown issues with it, which is why I didn't put it on the main page, but I think it is likely more stable than the older library even so. See reply #3 here:
https://decibel.ni.com/content/thread/17712
That having been said, while I would love it if you used and had feedback on the newer library, it looks like you do have everything configured correctly and the old one works well enough for common use cases like yours.The reason you are seeing an issue is because of a misunderstanding (an unfortunately common one) between a modbus address and the identifier of a coil, and the de-facto standard for identifying a coil. If you don't care about why this is, and just want the answer, skip past this section.
Specifically:
1) The address as defined by the standard is a value from 0 to 65,535. There are coils, DI, holding registers, and input registers. Each is identified by that same address range. Only the function code determines what the actual data is that is associated with that address. Some devices, which are really awkward to use, actually have different behaviors if you read address 0 as compared to when you write to address 0. As ridiculous as that sounds, it is nominally within the specification.
2) There is the concept of an actual data item. For example, there are 65,536 coils ranging from number 1 to number 65,536. When reading one of these coils you use function code 0x01 and you use an address from 0 to 65,535. In short: data items are referred to with 1-indexed names and are addressed using 0-indexed addresses. But it gets worse...
3) At some point, people decided that the naming conventions for modbus were not confusing enough and assigned the very weird order of:
1-Coils (corresponds to function 0x01)
2-Discrete inputs (function 0x02, still going well)
3-Input registers (nooooo...this one is function 0x04)
4-Holding Registers (you guessed it, this data is accessed by function 0x03)
Normally, this then gives you a number to prepend to your data item. For example, your holding registers will be 400,001 through 465,536. But it gets more confusing still! Some people use 0 indexing here, so you actually get 400,000 to 465,535 (1-indexing is far more common). Some people truncate the number of addresses available and just use 40,001 through 49,999 (pretty common, as you saw).
Answer (probably):
The way your code is shown, you are asking for address 40,000 of the holding registers. This means that you are actually asking for register #40,001 or modbus data item #440,001. All these things are totally valid, but probably not what you want.
More likely is that your user manual is telling you that you want holding registers 1 & 2 (address 0 & 1) identified as modbus data items #40001 & 40002. As such, you should change your "starting address" to 0 and your "quantity" to 2, and that should work.
Good luck.
Oh, and re: your specific question. For TCP, unit ID is meaningless unless you are talking to a tcp->serial gateway, because you already have a unique identifier (TCPIPv4 addy). Transaction ID is used if you have a more asynchronous style of master, similar to what we have in the DSC I/O servers but very dissimilar to the modbus library. It is usually an auto-incrementing counter which is used to identify requests, in case your master has multiple outstanding requests.
I would guess the reason you are getting no errors but also no data is that error handling is less stringent in the older library. The newer library follows the spec a bit more closely, so I think it would throw an error in this particular case. On the other hand, its not the most useful error since there isn't a whole ton you can do about it--basically the slave is not following the spec.
