How can I generate an exception when the client writes a number out of range to my server? Also, I would like some vairables on my server to be read-only and other read / write. Any recommendation?
Pymodbus generally handles out of bound register access internally, a request to read/write a data block which is out of range would raise ExceptionResponse('Invalid Address') . On the client side , you can check if the received response is exception response by either checking isError() method on the response (pymodbus v1.5.0 and above).
Refer synchronous_server and synchronous_client
Also by default, Discrete Inputs and Input Registers are Read only and Holding registers and Coils and Read/Write. Any attempt to write to the read only datablocks raises an ExceptionResponse.
If you have specific requirements to make a range of holding registers/coils read only you can have a look at the various datablocks , to create a custom datablock refer custom datablock example
Related
I am having trouble understanding this. Upon searching I found
Sets a specific byte to buffer until before calling serialEvent()
This is from this link from the Processing Website
Serial event is the function, that the user states by putting in the Serial port defined as the function, if I’m not mistaken.
But I have seen bufferUntil(‘\n’) when nothing’s being sent to the Serial, so what is this doing, and what does it mean before calling serialEvent() this is put in setup how could it be called each time before a function? And I have also seen arguments like lf, so what is happening here, and how does it synergies with that serialEvent() function?
Thanks for the help, cheers!
With bufferUntil(lf) you set up your serial port to listen (write data to its buffer) until it gets a certain character (lf, which in the example you linked is the line feed character).
As you've noticed bufferUntil(lf) won't actually read any data. To read the data the port received you need to define an interrupt function where you call readString:
void serialEvent(Serial port)
{ inString = port.readString(); }
This function will be called (interrupting the normal flow of your program and hence its name) automatically as soon as the serial port receives the character you defined with bufferUntil(lf); that'll be until the line feed character for the example. After reading data from the port's buffer your program will return to wherever it was interrupted.
EDIT: What is a buffer? The buffer is either a software (a variable hidden in the library that you're using) or hardware (a bank of memory on the serial port chip) place where you store data coming to the port (this one is the reception buffer, but there is also a transmission buffer for the info you send out through the port).
Think of it as a bucket for bits or bytes. In an analogy with water flow coming out of the tap, you can open your tap and place a glass under it if you want to have a glass of water. But it might be that you want to drink your water later, so you can place a bucket (water buffer) to store water for you. In this case, the bufferUntil(lf) statement would be the action of placing the bucket and you can think of the serialEvent as the action of taking water from the bucket (the fact that you are using the bucket allows you to keep doing your errands around the house but at some point the bucket will overflow unless you either close the tap or start emptying it, and to do that you have to interrupt your normal flow of activities).
Why do we need buffers? Well, you could be polling (listening on the port from the main task of your software) continuously but then your code would be very inefficient. With buffers you're allowed to do other things (calculating stuff, reading data from sensors or whatever) and you'll only check the port when you're sure (because your routine was interrupted) when the data you want is there. In this case, the data you want is indicated with the character you used as an argument in the bufferUntil(lf) function.
I hope I did not overstretch the analogies.
In can4linux, a Linux CAN device character driver currently a proprietary FIFO
implementation is used. The driver supports more then on CAN channel
(MAX_CHANNELS) and each channel can be opened by more than one process
(CAN_MAX_OPEN). If a CAN message is received the message is copied in all the
receive FIFOs for that channel.
Currently it looks like:
msg_fifo_t rx_buf[MAX_CHANNELS][CAN_MAX_OPEN];
The fifo size and pointers are defined in the msg_fifo_t. rx_buf is therefore a
big two dimensional array of these msg_fifo_t structures.
How can I solve this with using kfifo?
If a user process wants to read from a special
CAN controller and it is the nth process opening for read, I want to get exactly enter code herethe right fifo (or fifo pointer).
ptr = rx_buf[can[x][n];
Any links for examples or hints are welcome.
I want to know how to receive data into another variable, not the APDU buffer.
It is possible call the method setIncomingAndReceive() or receiveBytes() to receive data into the APDU buffer. But I want for card to receive data into another variable, not the APDU buffer.
In case of sending a reponse APDU, the method sendBytesLong(byte[] outData, short bOff, short len) supports sending data from other array variables, not APDU buffer. But it seems that there is no method which supports receiving data into other variables.
I hope somebody knows the method or the sample code to receive the data into the other variable.
There is no way to do that. If you need to copy the incoming data to another buffer, simply copy it using Util.arrayCopyNonAtomic().
Side note: APDU.sendBytesLong() copies the data from your buffer into the APDU buffer and then sends it out. This API is provided just so that you don't have to do the copy in your applet.
I have bunch of records in my offcard application and I want to save them all in javacard,
The question is:
What is the best way of transferring data to Java Card?
Should I transfer all data record by record (each one with a APDU) or send all the records in just one APDU?
Of course I know the limitation size of APDU and I'm using extended APDU in order to send all data just in one extended APDU which is more than 255 bytes..
It does not matter much if you send your data in one extended length APDU or one single APDU security wise. It is however much better to send unrelated information using separate APDU's. This would make your application much more modular. Note that if you send related information using separate APDU's, you may need to keep state between those APDU's for validation purposes (e.g. you may have to send either none or all of them, or send the APDU's in specific order).
Furthermore, ISO 7816-4 only defines 2 byte status words to send back to the sender, e.g. 8A80 to indicate any error in the command data. This means that it is impossible to tell from the status word which of the records contains failure information.
Finally, there are certainly still readers and software out there that have issues handling extended length APDU's. So if your software is going to be used by other parties you may want to stick to normal length APDU's.
guys need some insight here.
I know the definition of a protocol, being new to this c++ programming is quite a challenging
task.I am creating a Multi-threaded chat using SDL/C++, this is a learning experience for me
and now i have encounter a hump in which I need to overcome but understanding it is a little more difficult than I had thought.I need to make a chat protocol of some sort, I think...but am stump. Up until this point i have been sending messages in strings of characters.Now that am improving the application to the point where clients can register and login, I need a better way to communicating with my clients and server.
thank you.
Create objects that represent a message, then serialize the object, send it over the network, then deserialize at the other end.
For example, you could create a class called LoginMessage that contains two fields. One for a user name, and one for a password. To login, you would do something like:
LoginMessage *msg = new LoginMessage();
msg->username = "Fred";
msg->password = "you'll never guess";
char *serialized_msg = serialize(msg);
// send the bytes over the network
You would do something similar at the other end to convert the byte stream back into an object.
There are APIs for creating message objects and serializing them for you. Here are two popular ones. Both should suit your needs.
Protocol Buffers by Google
Thrift By Facebook
If you want the serialized messages to be readable, you can use YAML. Google has an API called yaml-cpp for serializing data to YAML format.
UPDATE:
Those APIs are for making your own protocol. They just handle the conversion of messages from object form to byte stream form. They do have feature for the actual transport of the messages over the network, but you don't need to use those features. How you design your protocol it up to you. But if you want to create messages by hand, you can do that too.
I'll give you some ideas for creating your own message format.
This is one way to do it.
Have the first 4 bytes of the message represent the length of the message as an unsigned integer. This is necessary to figure out where one message ends and where the next one starts. You will need to convert between host and network byte order when reading and writing to/from these four bytes.
Have the 5th byte represent the message type. For example, you could use a 1 to indicate a login request, a 2 to indicate a login response, and 3 to indicate a chat message. This byte is necessary for interpreting the meaning of the remaining bytes.
The remaining bytes would contain the message contents. For example, if it was a login message, you would encode the username and password into these bytes somehow. If it is a chat message, these bytes would contain the chat text.