Hello everyone, I am facing some confusion regarding the data readings I am getting from a JUMO601 paperless recorder connected to an Omron NJ301-1100 PLC. The numbers I am receiving do not seem to make sense to me despite my attempts to scale them in different ways. I have PT100 sensors connected to the JUMO recorder's analog inputs 1 and 2. I have successfully set up a Modbus connection using the MTCP library provided by Omron, and the communication is working as I am getting values that correspond to the PT100 temperatures. The data types from the JUMO recorder are in floats. I am receiving the Modbus data in an array format, so I have utilized structured text (ST) to extract the desired data and combine two words into a Dword. Word[0] appears to have fluctuations, which I assume are due to decimal points in Celsius being read. On the other hand, Word[1] seems more stable, with the three digits representing the Celsius integer reading. Does the digit 4 in Word[1] have a specific significance, like confirming the proper connection of the PT100 sensor? Just for clarification, these readings were captured when the temperature was around 20 degrees Celsius (or 68 degrees Fahrenheit).
Test out different word combinations to ensure they convey the message you intend. Check out this link for a tool that demonstrates the different outcomes that can be achieved through swapping words or bytes: https://www.scadacore.com/tools/programming-calculators/online-hex-converter/
Instead of using a pt100 probe, consider using a 100 Ohm resistor to measure the temperature. A 100 Ohm resistor corresponds to 0 degrees Celsius. By reading the value and understanding its representation, you can troubleshoot potential issues such as big or little endian or LSB/MSB problems.
bb76 suggested experimenting with word and byte swaps to achieve expected results. This online hex converter tool provides various options for conversions: https://www.scadacore.com/tools/programming-calculators/online-hex-converter/. This valuable converter might be useful for converting to float-bigendian format on sysmac.
To correctly convert the hexadecimal value 0x4199317E into a float data type instead of a DINT, you will then achieve the accurate reading of 19.14.
If you want to achieve the desired outcome, using the function CopyDwordToReal is more appropriate than using Dword_To_Real.
It sounds like your data arrangement resembles a floating-point number structure, with Word[1] serving as the integer part and Word[0] representing the decimal part. Swings in Word[0] might indeed be capturing the decimal changes in temp. As for your question about digit 4 in Word[1], I'm not aware of any convention where '4' would specifically indicate proper PT100 sensor connection. Given the temperature you cited, a reading of '20' would indeed fit for Word[1]. My recommendation would be to reevaluate the significance of '4' and ensure that your data scaling and interpretation methods align with how JUMO601 organizes its data. It's fundamental to have a clear comprehension of what each bit implies within the Modbus data frame.
It sounds like you've done a fair share already in setting up your PLC and recorder, great job! In relation to your question about the digit "4" in Word[1], I don't think it inherently means anything like confirming a proper PT100 connection. Your assumption about the fluctuations in Word[0] is reasonable as it could be accounting for the decimal aspects of the temperature. However, to confirm this, try and validate by adjusting temperatures and monitor how the values change. I suspect you might have to further tweak how you're interpreting the float data from the JUMO. Sometimes PLCs and recorders have unique ways of representing floats which might make initial readings confusing. Good luck!
It sounds like you're on the right track with your setup and data interpretation! The fluctuations you're seeing in Word[0] could indeed be due to how the floating-point numbers are being represented, especially if there's any noise in the signal. As for Word[1], the digit 4 might not have a specific significance unless it's part of a defined scaling or configuration in your Modbus setup. However, since you're seeing stable values there, it could simply be an artifact of the reading at that particular moment. It might be worth double-checking the configuration of your PT100 inputs and any scaling factors applied in your software, as those can often lead to misunderstandings in the data you're receiving. If the readings stay consistent under stable conditions, that's a good sign!
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: 1. How can I troubleshoot inconsistent data readings from a JUMO601 paperless recorder connected to an Omron PLC? - To troubleshoot inconsistent data readings, you can try scaling the readings in different ways and ensure the correct setup of Modbus connection and data extraction process.
Answer: - The JUMO recorder provides data types in floats for its readings.
Answer: - You can utilize structured text (ST) to extract the desired data and combine two words into a Dword when receiving Modbus data in an array format.
Answer: - Fluctuations in Word[0] may be due to decimal points in Celsius readings, while the stability of Word[1 could indicate a more accurate integer reading of the Celsius temperature.
Answer: - The digit 4 in Word[1] may not have a specific significance related to the proper connection of the PT100 sensor; it could be part of the data representation format.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.