Thanks. OK, good idea. Will do
@adamg, that's awesome, I can't believe how helpful this community is. I really appreciate that you're willing to help out a beginner to this extent.
I'm trying to wrap my head around the code, especially the telegram function and how it interacts with the array. I am having a hard time googling any information about it! Can you point me in the right direction to educate myself?
My slave's "field name" or address is 1, and the register tables of interest go from #30-69, then from #100-200.
So my code (I think) should look like this:
// telegram 0: read registers
telegram[0].u8id = 1; // slave address
telegram[0].u8fct = 3; // function code (this one is registers read)
telegram[0].u16RegAdd = 30; // start address in slave
telegram[0].u16CoilsNo = 39; // number of elements (coils or registers) to read
telegram[0].au16reg = au16data; // pointer to a memory array in the Arduino
... then another for the 100-200 range. Am I going to reach some limits as far as data storage?
Is it wise to write all these values to an SD card right away? (I want to provide logging to SD in the future)
if (current_millis >= (print_millis+1000))
{
print_millis = current_millis;
for (int j =0; j<16; j++)
{
Serial.print("H");
Serial.print(j);
Serial.print(":");
Serial.print(au16data[j]);
Serial.print(" ");
}
Serial.println();
}
I understand this is going to print out anything in the data array. I'm not understanding the "j" and the "H".
Thanks again! Let me know how it goes. I'm going to try this code tonight with "simply modbus" and see how it goes.
@vinistois, no problem glad to help, and the community here is really good, the main reason I like working with the Photon.
The ātelegramā is only a structure. The elements of the structure are defined in the ModbusRtu.h library and the elements essentially tell the code in the .h library what to do. If you take a look in the ModbusRtu.h file, you can find where they really start to use the parameters around line 440.
For your application, what data types are addresses #30-69 and #100-200? I am assuming these are decimal addresses and not hex addresses as well? If these are input/holding registers, we may run into some issues with input buffers here. 239 words = 278 bytes and I remember seeing someplace in the .h file that the buffer limit was 64 bytes. We could try increasing that, but it would probably be safer to just to a few read references.
As for writing the values to an SD card; that is a good idea. I have not tried writing to an SD card from my Photon. I ordered a number of microSD SPI breakouts on eBay a few weeks ago. Iām hoping they arrive tomorrow
As for printing the array data, the H was just short for āHoldingā and the j is the element number of the array au16data that I wanted to print. It prints out in my serial monitor like "H0:# H1:# H2:# H3:# ā¦ where # is the value of the array element.
I still plan on trying this with a Miltilin 469 later today and will push it to see how may registers I can read at once.
fantastic.
Here is a sample of the documentation I am provided:
I also have an SD breakout I was going to attack next. If we can pull the data from modbus every 1-5 seconds and store it on SD, perhaps that would help overcome the 64 byte limit. There is a new SD library which looks like it will really help make this work.
So how does the program know where in the array to put each piece of data? How do we know how much data this particular array can hold?
Let me know how it works out with your device, Iām excited to try this too! For now I have to work with a slave emulator, because the actual target device is difficult to get to (which is why we want the photon in the first place!)
Ok this is working much better.
This code:
// telegram 0: read registers
telegram[0].u8id = 1; // slave address
telegram[0].u8fct = 3; // function code (this one is registers read)
telegram[0].u16RegAdd = 100; // start address in slave
telegram[0].u16CoilsNo = 3; // number of elements (coils or registers) to read
telegram[0].au16reg = au16data; // pointer to a memory array
is sending this request:
001 003 000 100 000 003 068 020
Iām no expert but it Looks right to meā¦
Hi @vinistois, So I was able to play with my Master device connected to an industrial salve with lots of registers to read. I āhitā the buffer limit reading around 28 registers. I tried increasing the buffer size declaration variable in the .h file, but no luck. However, performing multiple reads worked OK problem so I donāt plan on digging too deep into the buffer. I have my Photon configured as a master connected to a Multilin 469 and was able to read 128 registers using 6 read requests. I think it needs more testing though; I want to let it run for a while reading timer values and see what differences or errors I encounter.
As for your code: it looks good to me as well. You are trying to read 3 registers starting at address 100 (Decimal!) from slave 1 with function code 3 (read holding registers). From the device documentation you provided it looks like you are using Hex addressing, so you will have to adjust you Photon code for that. As for your sending request, I am not very familiar with the raw requests. The raw requests I get for your example is ā01 03 00 64 00 03ā assuming all Hex. What is the 068 for?
Did you have any luck getting the Photon to communicate with Simply Modbus? I havenāt used that software in a few years but could give it a shot tomorrow
Does anyone know whether Nick Gammonās code can be made to work easily on the Spark Photon? His libraries seem well done at first glance and solve many basic needs. Any suggestions on the best way to develop a simple RS-485 based multiple-client simple app would be appreciated.
If you are refering to this
http://www.gammon.com.au/Arduino/RS485_protocol.zip
Then there is no real hardware specific code that should prevent the use of it as is.
Iāve been reading many chains related to the Photon and RS485/Modbus and I still canāt seem to figure out why folks arenāt simply using the Modbusmaster library available through the Web IDE. Is there an obvious reason or deficiency that Iām missing?
I loaded up the Modbusmaster, but unfortunately ran into hardware issues that have delayed my actual testing of it? Am I going to be disappointed?
If both of these approaches work, is there a reason why one would be preferable?
Thanks.
Has anybody seen this Hackster project for that matter?