Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

where could I store per connection variables? #17

Closed
galoko opened this issue Apr 10, 2018 · 5 comments
Closed

where could I store per connection variables? #17

galoko opened this issue Apr 10, 2018 · 5 comments

Comments

@galoko
Copy link

galoko commented Apr 10, 2018

where could I store per connection variables? I mean lets picture the situation: device connects to my slave server, write multiple registers and then read holding registers, I generate values in holding registers based on written registers values. So where exactly should I keep these values in-between of onWriteMultipleRegisters and onReadHoldingRegisters calls? I'm kinda out of options here or so it seems

@kevinherron
Copy link
Contributor

I'm not sure what you mean you're out of options... you have infinite options. I purposely do not implement any kind of process/register map abstraction because everyone's use case is different.

Put them in a Map<Integer, Integer> or get as complicated as you'd like?

@galoko
Copy link
Author

galoko commented Apr 11, 2018

well, this is a first thing that comes to mind, but if only I could use AttributeMap interface of Channel so I could actually store my context in a connection, that would be much better, isn't it?

@kevinherron
Copy link
Contributor

kevinherron commented Apr 11, 2018

Modbus register and status values are not traditionally per-connection - it's supposed to be a global address space.

@kevinherron
Copy link
Contributor

kevinherron commented Apr 11, 2018

If ServiceRequest gave you access to the Netty Channel would that work for you?

edit: Mmm, might not be that easy, this interface has to work for RTU support as well, where there won't be a Channel.

@galoko
Copy link
Author

galoko commented Apr 11, 2018

That would be perfect, thank you. In fact this is how I changed your code in order to continue with my project, but I felt a little off about it.

edit: well, it can return null for RTU for all I care, I use only TCP right now, so... at least it's better than nothing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants