Is there any way to read and display the dalla onewire temperate probe data?
LCDC has options to di ti but LCD Smartie dosnt seem to...
Maybe I can write a plugin to do it? Can the plugins send/read data from the serial link? I want to be able to log the temeratures to disk as well as display them on the LCD...
Many thanks,
Phil
Our new official repo is on github
LCD Smartie version 5.6 is released!
Download it now: https://github.com/LCD-Smartie/LCDSmartie/releases
LCD Smartie version 5.6 is released!
Download it now: https://github.com/LCD-Smartie/LCDSmartie/releases
MatixOrbital read temerature probes
Moderators: _X7JAY7X_, caesar, IFR, mattcro, limbo, Fast351
-
Philg
- Plugin Author
- Posts: 27
- Joined: March 4th, 2006, 1:10 pm
- Location: UK
- Contact:
-
ReverseEngineered
- Plugin Author
- Posts: 192
- Joined: January 18th, 2006, 11:09 pm
- Location: Saskatoon, Saskatchewan, Canada
It is quite possible to plugin to access this, but I must ask, what type of "serial link" are you thinking of? The dallas ds18s20 (and any of the 1-wire series) do not use the typical RS-232 serial that a computer uses, but rather a more complicated system by which this "1-wire" acts as power, clock, and data all at once. While it's fairly easy to make use of this with a microcontroller, and might be possible using the parallel port, it definitely won't just work with the serial port.
Since Smartie doesn't have a function to support writing to the disk (and I don't forsee it being necessary), I have an alternative suggestion for you. Instead of using Smartie to read directly from the temperature sensor, write a small program which reads from the sensor and logs it, but uses shared memory to make those readings accessible to a Smartie plugin. This would be ideal.
Since Smartie doesn't have a function to support writing to the disk (and I don't forsee it being necessary), I have an alternative suggestion for you. Instead of using Smartie to read directly from the temperature sensor, write a small program which reads from the sensor and logs it, but uses shared memory to make those readings accessible to a Smartie plugin. This would be ideal.
-
Philg
- Plugin Author
- Posts: 27
- Joined: March 4th, 2006, 1:10 pm
- Location: UK
- Contact:
I belive you miss-understand.
I have the Matrix Orbital MX 401 which connects to the PC via USB (on a virtual USB Serial Port (COM3))
You can plug upto 32 Dallas ds18s20's onto the display and acess the data on them from the PC, by sending the LCD commands and then reading the data it sends back (over the serial connection to the PC)...
The LCD device itself handles talking/listening to the sensors using the 1wire protocol!
The Matrix Orbital LCD manual describes the commands and responses.
I guess LCSSmartie can't do it right now, but can a plugin send / read data directly to/from the LCD??? thus allowing me to write a plugin to do this?
If not I guess LCD Smartie itself would have to be updated to support these LCD devices with temperature sensors (I would be willing to have a go but I'm not familiar with Delphi <yet!>)
Ideally, the plugin/lcdsmartie would send the command to the Matrix Orbital LCD display over the serial port, read the data and stuff it into some variable that LCDSmartie can output to the display. But as well as that, I would like to be able to write the values (data) recieved FROM the LCD to a file - so I can use it as a log and input to other applicaitons.
Thanks,
Phil
I have the Matrix Orbital MX 401 which connects to the PC via USB (on a virtual USB Serial Port (COM3))
You can plug upto 32 Dallas ds18s20's onto the display and acess the data on them from the PC, by sending the LCD commands and then reading the data it sends back (over the serial connection to the PC)...
The LCD device itself handles talking/listening to the sensors using the 1wire protocol!
The Matrix Orbital LCD manual describes the commands and responses.
I guess LCSSmartie can't do it right now, but can a plugin send / read data directly to/from the LCD??? thus allowing me to write a plugin to do this?
If not I guess LCD Smartie itself would have to be updated to support these LCD devices with temperature sensors (I would be willing to have a go but I'm not familiar with Delphi <yet!>)
Ideally, the plugin/lcdsmartie would send the command to the Matrix Orbital LCD display over the serial port, read the data and stuff it into some variable that LCDSmartie can output to the display. But as well as that, I would like to be able to write the values (data) recieved FROM the LCD to a file - so I can use it as a log and input to other applicaitons.
Thanks,
Phil
-
Philg
- Plugin Author
- Posts: 27
- Joined: March 4th, 2006, 1:10 pm
- Location: UK
- Contact:
More info on the commands needed to send here:
http://www.matrixorbital.ca/appnotes/1wire/1wire_intro
Im currently trying to implement a funciton in LCDSmartie to read the temerature probes, but its my first attempt at Delphi (I've used Pascal before but not in about 10 years!!!)
If anyone else wants to do this for me....
Thanks,
Phil
http://www.matrixorbital.ca/appnotes/1wire/1wire_intro
Im currently trying to implement a funciton in LCDSmartie to read the temerature probes, but its my first attempt at Delphi (I've used Pascal before but not in about 10 years!!!)
If anyone else wants to do this for me....
Thanks,
Phil
-
ReverseEngineered
- Plugin Author
- Posts: 192
- Joined: January 18th, 2006, 11:09 pm
- Location: Saskatoon, Saskatchewan, Canada
Don't get too anxious to go modifying Smartie just yet...
We're redesigning the entire thing. And I mean entirely. There's a lot that has to be done, and things are going to change quite significantly (internally, that is). Anything you write now will most likely not work once Smartie is updated.
That being said, there are a couple of things to keep in mind about the new design. For one, the design of the "display" is changing very little. In particular, it can handle basically any Crystal Fontz, Matrix Orbital, or similar display, including GPOs and keypad inputs. However, this doesn't include temperature inputs like you have mentioned. That display is a very special case, and supporting it would require a major change to the interface (to put it straight: a display shouldn't be doing any input period, but a keypad is quite common, so we're supporting it).
I'm not entirely sure how that display works, but there may be another way to use it. It would be possible to make the DLL for that display in two pieces: one that handles the output and one for the input. Obviously this will require a few tricks (like using semaphores between the two parts to ensure mutually exclusive access to the display), but it can be done without breaking our design model.
As with all the other requests we have had for new hardware support, we need to redo Smartie before we can begin supporting new hardware: there are just too many limitations in the current implementation. As soon as we finish that, we'll start supporting all kinds of displays.
We're redesigning the entire thing. And I mean entirely. There's a lot that has to be done, and things are going to change quite significantly (internally, that is). Anything you write now will most likely not work once Smartie is updated.
That being said, there are a couple of things to keep in mind about the new design. For one, the design of the "display" is changing very little. In particular, it can handle basically any Crystal Fontz, Matrix Orbital, or similar display, including GPOs and keypad inputs. However, this doesn't include temperature inputs like you have mentioned. That display is a very special case, and supporting it would require a major change to the interface (to put it straight: a display shouldn't be doing any input period, but a keypad is quite common, so we're supporting it).
I'm not entirely sure how that display works, but there may be another way to use it. It would be possible to make the DLL for that display in two pieces: one that handles the output and one for the input. Obviously this will require a few tricks (like using semaphores between the two parts to ensure mutually exclusive access to the display), but it can be done without breaking our design model.
As with all the other requests we have had for new hardware support, we need to redo Smartie before we can begin supporting new hardware: there are just too many limitations in the current implementation. As soon as we finish that, we'll start supporting all kinds of displays.
-
Philg
- Plugin Author
- Posts: 27
- Joined: March 4th, 2006, 1:10 pm
- Location: UK
- Contact:
Too late, Ive already modified my local copy of the smartie source and added code to read the temperature sensors.
As to it being a special case display - I have to disagree - more and more displays (all new ones from Matrix Orbital) seem to support these I2C probes - so it would't go a miss to support it in my opinion...
The only reason I bought it was because it could have these temp probes attached and i wanted a relativly cheap method of reading temperatures - the fact that it has an LCD and keypad was an added bonus.
In the end, I may end up writing my own code from scratch in a language more familiar to me (c# for example) but until then, Im happy to have my own custom version of smartie 5.3 if your not going to implement this in the base product.
I made the changes by adding 2 functions to the LCD interface - not particually difficult, and not particially special (my Delphi isnt great seeing as I only started using it yesterday - but it works for me)... I havnt actually tied it up into variables yet - but that cant be too difficult can it
If the new design is also open source, then it wont be difficult to add these extra functions to smartie... But if your redesigning it anyway, why not allow plugins to send/recieve data directly to the display - provided through a funciton call to the Smartie interface which maps to the writeData/readData functions... That way, this can be done, from a plugin, without the complexity of semaphores etc... That would give the ability to extend the main smartie funcitonality for displays with new features without having to modify the base product (something I'm all for in general!)
Thanks,
Phil
As to it being a special case display - I have to disagree - more and more displays (all new ones from Matrix Orbital) seem to support these I2C probes - so it would't go a miss to support it in my opinion...
The only reason I bought it was because it could have these temp probes attached and i wanted a relativly cheap method of reading temperatures - the fact that it has an LCD and keypad was an added bonus.
In the end, I may end up writing my own code from scratch in a language more familiar to me (c# for example) but until then, Im happy to have my own custom version of smartie 5.3 if your not going to implement this in the base product.
I made the changes by adding 2 functions to the LCD interface - not particually difficult, and not particially special (my Delphi isnt great seeing as I only started using it yesterday - but it works for me)... I havnt actually tied it up into variables yet - but that cant be too difficult can it
If the new design is also open source, then it wont be difficult to add these extra functions to smartie... But if your redesigning it anyway, why not allow plugins to send/recieve data directly to the display - provided through a funciton call to the Smartie interface which maps to the writeData/readData functions... That way, this can be done, from a plugin, without the complexity of semaphores etc... That would give the ability to extend the main smartie funcitonality for displays with new features without having to modify the base product (something I'm all for in general!)
Thanks,
Phil
-
Philg
- Plugin Author
- Posts: 27
- Joined: March 4th, 2006, 1:10 pm
- Location: UK
- Contact:
Ok, now I have it all nicely integrated - you can select from a list of temp sensors on the device specific smartie tab (if its a MO device and it has DALLAS temp sensors connected each will be listed)
And when processing the data, it reads the temp from the device....
Here is a screenie of it working:
If you want the code, so you can look at it, and maybe add it later, let me know. As I said its not pretty but it works - Im sure a decent Delphi coder can make it more efficient etc...
Phil
And when processing the data, it reads the temp from the device....
Here is a screenie of it working:
If you want the code, so you can look at it, and maybe add it later, let me know. As I said its not pretty but it works - Im sure a decent Delphi coder can make it more efficient etc...
Phil