> configuring the MODBUS plug-in is a bit tricky. The reason: there are some devices out there that work with wrong
> byte order (according to MODBUS specification) and some that use wrong address offsets (and some that do both
> wrong). So when you configure a plug-in for your device you in most cases will not have exact specification of this
> devices behaviour, so you only can try all variants: invert/non-invert address/data byteorder, start with an address
> counting from 0/1.
I’ll go along with that but it appears as if un-checking the box gives small-endian byte order, and checking it gives big-endien. The box is checked by default so I suppose it makes a sort of sense.
In version 3.3.2 the return value appeared to be in the wrong order as well though, I had to divide by 256 to correct it.
Version 3.6 doesn’t appear to receive at all, So far I’ve tried effectively the same device program but on two different microcontrollers, and a example device program that outputs a continuous count value on register 999.
A raw com-port dumper would be really useful at this point.
Incidentally the “DLL hell” issue is that if you uninstall OpenAPC 3.6 and reinstall 3.3.2 then you get an odd error and it won’t run. Windows XP and 7. It means I can’t readily switch between them unless I do something messy like putting OpenAPC in a virtual machine. I’ve got the error message saved somewhere, can’t find it now. At work I managed to roll the system back enough to clear it but this home machine’s had 3.6 on too long, system restore would muck up too many other things.
I'm trying to implement a ModBUS RTU device on a microcontroller development
board. I'm using "Qmodmaster" for testing as it can show the byte-by-byte
communication between the PC and device, and so far the device behaves
I'm also trying to access the device from OpenAPC. I can't use Modbus RTU at
all in version 3.6, it appears to communicate something but the device only
I've had more success with version 3.3.2, in that version I am able to send
the state of four buttons to the device as a "holding register" and read the
My specific problems:
Byte ordering. Currently I have both boxes checked and it appears to work,
but why is there a need for this? As far as I'm aware Modbus RTU 16-bit
integers are always big-endian and bits (coils) are packed as bytes so there
should be only one valid byte ordering.
Return values currently appear to be multiplied by 256. This would imply a
byte-swap. There could be a problem with my device but I doubt it as
qmodmaster can access it consistently.
When the modbus block reads a state it appears to only outputs a value when
the state changes. This would appear to mean that if a register's state
remains constant the value never propagates. It ought to be propagated at
least once on the first poll.
HelloI have 2 problem's:
- when i try to import a STL file for slicing in BeamConstruct the orientation is wrong (Z axis become Y axis, so i need to rotate every time 90 by X axis). I tried with several STL files from different software's and even downloaded from internet.
- Is very frustrate to center a sliced STL in BeamConstruct, i select "Show 3D Mesh" so i can edit the geometry, but the "Center" buttons are disabled. I have to place it manually (the biggest problem with manual placing is on the Z axis, there the bottom of the model need to be exact)
P.S. I spiked with Mr. Michael about too!!