Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 17 18:52
    tracernz commented #444
  • Sep 17 15:50
    dhoomakethu commented #444
  • Sep 17 15:25
    starnight commented #444
  • Sep 17 15:24
    starnight commented #444
  • Sep 17 15:23
    starnight commented #444
  • Sep 17 15:21
    starnight commented #444
  • Sep 17 15:15
    starnight synchronize #439
  • Sep 17 11:17
    saanchezfer commented #443
  • Sep 17 02:53
    dhoomakethu commented #444
  • Sep 17 02:50
    dhoomakethu commented #432
  • Sep 17 02:50
    dhoomakethu labeled #432
  • Sep 17 02:49
    dhoomakethu closed #434
  • Sep 17 02:49
    dhoomakethu commented #434
  • Sep 17 02:48
    dhoomakethu commented #438
  • Sep 17 02:48
    dhoomakethu commented #438
  • Sep 17 02:42
    dhoomakethu edited #438
  • Sep 17 02:41
    dhoomakethu commented #438
  • Sep 17 02:40
    dhoomakethu labeled #438
  • Sep 17 02:40
    dhoomakethu labeled #438
  • Sep 17 02:40
    dhoomakethu labeled #438
jleman
@jleman

I now have Pymodbus working (thanks to your help) and am able to get communications working between the PyModbus server and a simulated Modbus master (not Pymodbus). Now I am moving the Modbus master to a virtual machine behind a router. I have routing tables set up so that I can ping between the host machine (housing the PyModbus server) and the virtual machine (housing the Modbus master). How should I set the addressing within the PyModbus server so they can continue to communicate?

StartTcpServer(context, identity=identity, address=("?", 502))

The virtual machine host of the Modbus master has IP address 10.0.10.1 and the non-vritual host has IP address 10.011.1.

jleman
@jleman
Also, I notice some examples listen on port 502, others 5020. Does it matter which port?
Jouzer
@Jouzer
@jleman Probably too late but replying anyway, the 502 is the "well known port" for Modbus TCP = almost always that's the port you'd use in a field application. I believe 5020 is imported in the examples because running the script in my ubuntu (at least) required sudo for ports below 1000
Harold Howe
@hhowe29

Hey all. I have a question on the intent of zero_mode=False in server code and how it jives with ModbusSequentialDataBlock. I have this server code. I would like to strictly use 1 based addressing to adhere to the modbus spec.

store = ModbusSlaveContext(
    co=ModbusSequentialDataBlock(1, [1, 0, 0, 1, 1, 0, 0, 1]) # block of 8 coils starting at address 1
)
context = ModbusServerContext(slaves=store, single=True)
identity = ModbusDeviceIdentification() # config snipped 
StartTcpServer(context, identity=identity, address=('', 8080))

ModbusSequentialDataBlock acts like I expect. It translates a read of address 1 to self.values[0] by way of this line.

However, these two lines in ModbusSlaveContext convert address 1 to a 2, and that reads the second item in the sequential block. This seems like a bug to me. The only way for the client to get at the first item in the block is to pass an address of 0, but that should be invalid when zero_mode is False, correct?

# client code
client.read_coils(1, 1) # returns 0 instead of 1
client.read_coils(0, 1) # returns 1 and not an address error
client.read_coils(1, 8) # illegal address error
client.read_coils(0, 8) # returns entire block. No illegal address error

I could work around this by creating sequential blocks with 9 values starting at address 0, and just letting that first item go to unused, but this approach seems wasteful and kind of dirty. Setting zero_mode to True just works, which is what gets recommended in GH issues similar to my question. I can do that, but it seems kind of wrong as well

Any thoughts or suggestions?

Harold Howe
@hhowe29
After digging into this a bit more, I think I may be confusing modbus entity numbers (1 based ) with entity addresses (0 based ) (see wikipedia). pymodbus seems to work exclusively with address. I still think zero_mode=False is jacked up, but I am just going to set it to True and use 0 based addressing throughout. Many of the examples in the docs use address 1, which gave me the impression that I should be thinking in the 1 based world.
Bill McCormick
@wpmccormick_gitlab
Is there an example for a sync or async serial server? I need something very simple for testing.
Bill McCormick
@wpmccormick_gitlab
So after looking closer, I see that synchronous_server.py includes a StartSerialServer, whci is exaclty what I was looking for with the RtuFramer. When I run my client against it howerver, I have CRC issues:
bill@billdoze:~/src/wambslave$ ./synchronous_server.py
2019-07-24 16:40:41,069 MainThread      DEBUG    sync           :45       Client Connected [/dev/ttyS5:/dev/ttyS5]
2019-07-24 16:40:41,069 MainThread      DEBUG    sync           :522      Started thread to serve client
2019-07-24 16:40:43,961 MainThread      DEBUG    rtu_framer     :232      Frame check failed, ignoring!!
2019-07-24 16:40:43,962 MainThread      DEBUG    rtu_framer     :128      Resetting frame - Current Frame in buffer - 0x1 0x20 0x0 0x1
2019-07-24 16:40:43,969 MainThread      DEBUG    rtu_framer     :232      Frame check failed, ignoring!!
2019-07-24 16:40:43,969 MainThread      DEBUG    rtu_framer     :128      Resetting frame - Current Frame in buffer - 0x98 0xf8
2
dhoomakethu
@dhoomakethu
@wpmccormick_gitlab can you share your code ?
Bill McCormick
@wpmccormick_gitlab
I'm using the synchronous_server.py example; the only change I made was to uncomment the StartSerialServer and comment the StartTcpServer.
Ahh ... sorry, just found the issue: a 5ms timeout was too fast.
Bill McCormick
@wpmccormick_gitlab
So now I try the same test using the asyncserver and more problems:
INFO:pymodbus.server.asynchronous:Starting Modbus Serial Server on /dev/ttyS5
DEBUG:pymodbus.server.asynchronous:Client Connected [/dev/ttyS5]
DEBUG:pymodbus.server.asynchronous:Running in Main thread
DEBUG:pymodbus.server.asynchronous:Data Received: 0x1
DEBUG:pymodbus.framer.rtu_framer:Frame - [] not ready
DEBUG:pymodbus.server.asynchronous:Data Received: 0x3 0x0
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x1 0x3 0x0
DEBUG:pymodbus.server.asynchronous:Data Received: 0x0 0x0
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x0 0x0
DEBUG:pymodbus.server.asynchronous:Data Received: 0x1 0x84 0xa
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x1 0x84 0xa
DEBUG:pymodbus.server.asynchronous:Data Received: 0x1
DEBUG:pymodbus.framer.rtu_framer:Frame - [] not ready
DEBUG:pymodbus.server.asynchronous:Data Received: 0x3 0x0 0x0 0x0 0x1
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x1 0x3 0x0 0x0 0x0 0x1
DEBUG:pymodbus.server.asynchronous:Data Received: 0x84 0xa
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x84 0xa
DEBUG:pymodbus.server.asynchronous:Data Received: 0x1
DEBUG:pymodbus.framer.rtu_framer:Frame - [] not ready
DEBUG:pymodbus.server.asynchronous:Data Received: 0x3 0x0
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x1 0x3 0x0
DEBUG:pymodbus.server.asynchronous:Data Received: 0x0 0x0
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x0 0x0
DEBUG:pymodbus.server.asynchronous:Data Received: 0x1 0x84
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x1 0x84
DEBUG:pymodbus.server.asynchronous:Data Received: 0xa
DEBUG:pymodbus.framer.rtu_framer:Frame - [
] not ready
DEBUG:pymodbus.server.asynchronous:Data Received: 0x1
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0xa 0x1
DEBUG:pymodbus.server.asynchronous:Data Received: 0x3 0x0 0x0 0x0 0x1 0x84 0xa
DEBUG:pymodbus.framer.rtu_framer:CRC invalid, discarding header!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x3 0x0 0x0 0x0 0x1 0x84 0xa
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer -
Bill McCormick
@wpmccormick_gitlab
Additionally, the syncserver will not work again until I reset (disconnect/reconnect) my USB/485 converter.
Bill McCormick
@wpmccormick_gitlab
Should it be possible to run both serial and tcp servers at the same time against the same slave context/data blocks? The use case is for testing/changing values using the tcp client, that a serial client is accessing.
Bill McCormick
@wpmccormick_gitlab
So it looks like the answer to my last question is no. I do see however, a number of examples that use the concept of a shared/remote context; but not in the way I think I need
Bill McCormick
@wpmccormick_gitlab
My setup is as follows: I have a hardware Modbus client device that wants to read holding registers from a server/slave device over Serial RTU. I have tested running that device against the synchronous_server example, and so far; so good. Now I want to be able to change those holding registers without disconnecting the hardware device, so I'm looking for an example that does that part - that is, writing a new value to a holding register from some device/client other than the hardware device. It feels like doing this is feasable within the existing pymodbus framework, and being a fan of not re-inventing the wheel, I shure would like to realize this. Any help would be appreciated.
@wpmccormick_gitlab
Bill McCormick
@wpmccormick_gitlab
Yes, late Friday after my last message I found that. However the issue I had (and noted here) with the Seial RTU async example I have here as well.
chshanoo
@chshanoo
Hey hope you all doing well. I am struck in a problem kindly someone have a look at it & do help me out.
Issue i am facing is while reading holding registers i get data as expected but most of times it give error 'ModbusIOException' object has no attribute 'registers' . Although code is working but mostly shows error.
here is my code detail & output
https://stackoverflow.com/questions/57309462/modbusioexception-object-has-no-attribute-registers-although-code-is-worki
Mark Jones
@OldTinfoil
Hey all
Joined the lobby to pick brains about pidfiles + servers, but I figured it out now
This lobby is livelier than I would have otherwise thought
saanchezfer
@saanchezfer
image.png
Hi! I want to connect to a device that is using this https://www.usriot.com/products/rs232-to-ethernet-converter.html converter in the middle. I can connect directly via serial, and emulating a virtual serial port using the ip that the converter have, but i want to connect without emulating the port. I tried that mbClient = ModTcp(host='10.0.4.103', port=10002, framer=ModbusRtuFramer) but it is still not working. Ideas? Ty
Mark Jones
@OldTinfoil
FWIW - I'm not sure that I'm the right person to help you, but I'm not following you.
Bill McCormick
@wpmccormick_gitlab
It's actually pretty dead here. Check the dates on the posts.
Mark Jones
@OldTinfoil
@wpmccormick_gitlab - I was expecting there to be an old backlog of "halp me" requests going unanswered :)
@saanchezfer Initially you had: YOU <-- Serial --> Connector <-- Ethernet --> Device and now you're trying to do: YOU <-- Ethernet --> Device?
Bill McCormick
@wpmccormick_gitlab
Unfortunately, you're expectations have been met
?
what?
Mark Jones
@OldTinfoil
To which bit?
Bill McCormick
@wpmccormick_gitlab
"Initially you had: YOU <-- Serial --> Connector <-- Ethernet --> Device and now you're trying to do: YOU <-- Ethernet --> Device?"
Mark Jones
@OldTinfoil
Trying to follow what saanchezfer is trying to do with his rs232 -> ethernet converter
Bill McCormick
@wpmccormick_gitlab
Oops sorry
Mark Jones
@OldTinfoil
That's fine - was wondering if I had accidentally produced unintelligible gibberish!
dhoomakethu
@dhoomakethu
@saanchezfer are you using the correct port on the device?
Never mind, I went through the URL you shared and it looks like the device does not talk modbus protocol
Nothing much pymodbus can help in that case
@wpmccormick_gitlab I am sorry if any of your questions have been unanswered here. I try to answer as much as possible whenever possible .
Bill McCormick
@wpmccormick_gitlab
Ok thanks. Is now whenever? And is now possible?
Bill McCormick
@wpmccormick_gitlab
I guess not. My questions are still out there.
Mark Jones
@OldTinfoil
Are you using an RTU framer for the IP server?
Is there a remote device trying to update the IP server? Or are you just using it for loopback?
saanchezfer
@saanchezfer
@dhoomakethu yes. And yes, it talks modbus protocol because we can read it directly, and emulating its ip in a serial port. The problem is the converter in the middle. It only answers via serial, but we can't connect directly to it.
@OldTinfoil @wpmccormick_gitlab no, i have me - ethernet - converter- serial - device. and what you say it's what i'm exactly trying
Mark Jones
@OldTinfoil
@saanchezfer - Does the converter know how to speak rtu over IP? What happens if you use the default framer?
saanchezfer
@saanchezfer
@OldTinfoil nothing happens. just connection error. the only way i know to connect is emulating a virtual serial port with the software that the converter have and in the code using the modbusserialclient . the soft is called usr vcom
solarjoe
@solarjoe
Just out of interest, what is the reason for ReconnectingAsyncioModbusTcpClient not inheriting or mix-in from AsyncioModbusTcpClient but being a class on its own?