envirodiy / sensormodbusmaster Goto Github PK

Not using RS485 at all, and compared to another modbus library that was going to force me to write what you have on top of it, im having some issues reading it the same, seems all my bits on an 8n1 setup are shifted 4. I think its due to some rs485 overhead. Any suggestions? Amazing library btw.

I am trying to communicate with a VFD (Variable Frequency Drive) via Modbus, I've tried several libraries some did not work some were too slow for some reason and I wanted to give a try to your library but I get no response from Serial monitor, seems board is stuck once upload is complete.

VFD's(slave) address is 1, baudrate is 38400 and has even parity.(8E1)

below I am trying to read the value of 9604 or write to 8602 but nothing happens as mentioned above. I am using Arduino Mega.

#include <SensorModbusMaster.h>


// Define the sensor's modbus address
int modbusAddress = 1;  // The sensor's modbus address, or SlaveID

// Create the stream instance
HardwareSerial modbusSerial = Serial1;


modbusMaster modbus;

void setup()
{
  Serial.begin(9600);
  //baudrate
  modbusSerial.begin(38400);  // port for communicating with sensor
  //modbusSlaveID, modbusSerial, enablePin
  modbus.begin(modbusAddress, modbusSerial, 3);

}

// ---------------------------------------------------------------------------
// Main loop function
// ---------------------------------------------------------------------------
void loop()
{
  float rated = modbus.uint16FromRegister(0x04, 9604, bigEndian);
  Serial.print("rated hz ");
  Serial.println(rated);
  delay(2000);
  modbus.int16ToRegister(8602, 56, littleEndian);
  delay(2000);
  }

Is there any way to use this library directly on esp8266?

This last fall I started seeing Modbus communication failures with a very inexpensive batch of RS-485 adapters that I purchased for the Modbus-Mafly-WingShield. What I observed was that the TXD and RXD lights on the RS-485 adapter would weakly and rapidly flicker on the adapters that didn't work. On the adapters that did work, the TXD light would blink strongly once, and the RXD light would soon follow with a strong blink.

At that time, I figured the issue was due to inferior quality of the very inexpensive adapters (which looked nearly identical, BTW), so I ordered the more expensive SMAKN SCM TTL to RS485 Adapter. Those worked and I had other deadlines, so I didn't think anything of it... until I purchased another batch from SMAKN a few weeks ago, and they all had the same faintly flickering light issue issue!

@neilh10, appears to have just had the same issue, which he posted to #5 (comment)

The good news is that I just figured out the solution last week, so I'm creating this issue to remind me to fully document it. Below is from my response to @neilh10.

The SOLUTION: solder a 120 ohm resistor between the A+ and B- data lines as "termination" to prevent data signal reflections. A 100 or 150 ohm resistor also worked for me.

These are my info sources:

• https://www.maximintegrated.com/en/design/technical-documents/tutorials/7/763.html
• https://www.csimn.com/CSI_pages/RS-485-FAQ.html

Technically, the terminating 120 ohm resistor is supposed to be placed at the end of the sensor chain, but it worked for me to solder it right onto the RS485 adapter board.

I'm having an issue with a KellerParent request dying.
It works if the MS_KELLERPARENT_DEBUG_DEEP is enabled.
This used to work for me with AVR, but now using it with ARM/SAMD so investigating why its different now.

KellerParent.cpp
On MS_KELLERPARENT_DEBUG_DEEP
#ifdef MS_KELLERPARENT_DEBUG_DEEP
sensor.setDebugStream(&DEEP_DEBUGGING_SERIAL_OUTPUT);

It sets up the output for SensorModbusMaster_ID1824\src\SensorModbusMaster.cpp "0.6.5"
_debugStream->print("Raw Request >>> ");
which results in SensorModbusMaster_ID1824\src\SensorModbusMaster.h
void setDebugStream(Stream *stream){_debugStream = stream;}

however the standard case with no MS_KELLERPARENT_DEBUG_DEEP has _debugStream uninitialized - which is likely to be 0's or NULL
Stream *_debugStream; // The stream instance (serial port) for debugging
which would cause a FAILURE when executing
NULL->print("Raw Request >>> ");

I think the solution is to put a check in
For SensorModbusMaster.h _debugStream rename to _debugStream1
in SensorModbusMaster.cpp
#define _debugStream if (_debugStream1 != NULL) _debugStream1->print("Raw Request >>> ");

So checking in if anybody else has seen this and/or any other solution.

Are you using control for TE and DE? Or are you depending auto direction control?

As discussed in PR #2, Extra documentation is needed in the main ReadMe, and also in the hardware Readme.

Need to remove Docs at https://github.com/EnviroDIY/YosemitechModbus#suggested-setup-with-an-envirodiy-mayfly

This would also close EnviroDIY/YosemitechModbus#10

First of all, I must say that it is a joy to use your library; its simple yet does all (except 1) I require to interface with my modbus device to an arduino nano. The only issue is that my modbus device required 8N2 (and the nano has only 1 hardware serial connected to the pc usb); so I cant use AltSoftSerial or SoftwareSerial. Would it be possible for you to add support for the CustomSoftwareSerial library (https://github.com/ledongthuc/CustomSoftwareSerial)?

Thanks

The scanRegisters sketch is NOT an example of using this.

Hey,
i have used your lib for a long time. I was very happy with it.
Now i am looking for a function for float to CDAB Mid-little endian.
And other direction from CDAB Mid-little endian to float
Can you tell me a small hint for adding this function?

The RS485 hybrid has some defined lightening or ESD clamping components.
There has been some discussion of this elsewhere.
However, my analysis, is that the clamping components need a a low impedance path to ground.
I've added a thick grounding wire to the hybrids ground connection, that can then be connected to an external earth connection. I'm using solid core that I have to hand 18 AWG, or 1mm dia. Ideally it should be green. I'm making the tail 12" long, and it can be trimmed on installation if necessary.

Background: As an EE, I've seen a number of boards that have conducted lightening currents - been hit by lightening. The number one rule is that shouldn't burst in to flames, potentially causing further damage.
While grounding circuits are not guaranteed to conduct all large currents to ground, having a low ohmic resistance to ground is a starting point.
For areas that have a large number of lightening strikes, local knowledge and code usually defines how a good electrical ground is formed.
There is an IEEE specification on grounding but I haven't got a direct reference on it.
Living in California, while lightening isn't common, we've just been through a storm that was estimated to have created 12,000 strikes, which then caused some 600fires.
The state with the most lightening strikes is supposed to be Florida. However the subsoil is largely on a reef, and I've been to technical presentations that say Florida is the most difficult to form a good ground.

Hi, i trying to use this library on Mega:

HardwareSerial modbusSerial = Serial2;
modbusMaster modbus;

modbusSerial.begin(2400);
modbus.begin(101, modbusSerial);

float val = modbus.uint16FromRegister(0x04, 1, bigEndian);

TTL to RS485 adapter blink 8 times TX on boot, then Mega hangs on any type read register attempt.
Any suggestion how to debug this?

In the example there are two variables assigned to pin 10. sensorPwrPin and SSRxPin is this correct?
Seems to me this is a conflict?

What is the typical usage for

float modbusMaster::float32FromRegister(byte regType, int regNum, endianness endian)
 {
     getRegisters(regType, regNum, FLOAT32_SIZE/2);
     return float32FromFrame(endian);
 } 

can i call it by: reg1 = modbus.float32FromRegister(0x04, 0x01, bigEndian);?
or do i need to include the rest of the function between the {}?
I'm just a nube learning arduino...

First of all, I must say that it is a joy to use your library.
Please add support of your library to Arduino portenta C33.

Could a component list be added - or a pointer to where to find it.

Its nice to see the gerbers and be able to generate a PCB from them - but I can't see any BillOfMaterials that is traditionally used to list partnumbers.

Personally, with my schematics I usually make an identifier indication visible on the schematic, but I guess everyone is different.

When I try and list the parts in Eagle 9.1 it doesn't show them.

the library is one of the best out there but has no modbus error check, is there any one that can contribute for that?
some of the most common errors.
enum ERR_LIST {
ERR_NOT_MASTER = -1,
ERR_POLLING = -2,
ERR_BUFF_OVERFLOW = -3,
ERR_BAD_CRC = -4,
ERR_EXCEPTION = -5
};

enum {
NO_REPLY = 255,
EXC_FUNC_CODE = 1,
EXC_ADDR_RANGE = 2,
EXC_REGS_QUANT = 3,
EXC_EXECUTE = 4
};
as referece this library can be used to implement errors check:
https://github.com/pkourany/ModBus_RS485_Slave

@aufdenkampe I think it should stand on its own, since it's only proximal to the library.

i noticed that any getXXXFromRegister call takes ~31ms, so i dug deeper and found that in getRegisters() it adds a Delay of 25ms presumably for when the message fails and then wants to retry (correct me if im wrong).

Long story short: i changed

while (respSize != (numRegisters*2 + 5) && tries < 10)
    {
        // Send out the command (this adds the CRC)
        respSize = sendCommand(command, 8);
        tries++;

        delay(25);
    }

to

while (respSize != (numRegisters*2 + 5) && tries < 10)
    {
        // Send out the command (this adds the CRC)
        respSize = sendCommand(command, 8);
        tries++;

        if(respSize != (numRegisters*2 + 5)) {
            delay(25);
        }
    }

So it only adds the Delay if the response size is wrong, works for me, and now i have times of ~7ms per call.

You could argue that modbus needs these delays, but as for now i dont see anything where its needed, and the sendCommand() actively waits for a response with a delay of 1ms until it gets an answer anyways, so i see this as a worthy performance improvement.

Support the Mayfly 1.1 +12V_SW.

The Mayfly 1.1 can generate +12V_SW of 12V at 5W of power.
However the Mayfly 1.1 has NO path power switch. When the boost is disabled, there is still a power path to the input through a diode.

There is a benefit of being able to turn on the boost (typically +12V), allow it to stabilize.
Then when stable the +12V can be applied to the external +12V circuit.