Forum Replies Created
-
AuthorPosts
-
in reply to: SSR Output Switching Rate #3944
I have significantly rewritten the firmware to handle two PID loops, two inputs, and two outputs. I’m still in the process of rewriting the frontend to handle all of the firmware changes and a drastically modified serial comms protocol. It is completely incompatible with the osPID hardware, as I’ve gone to SPI for the button/LCD interface, and it’s designed for a 16×2 LCD instead of an 8×2, with 8 buttons. Waiting for PCB’s to show up from Seeed Studio for the prototype. I’ll post more info once the prototype is up and running.
in reply to: SSR Output Switching Rate #3942Another suggestion Brett gave me, which I am utilizing in my dual channel PID firmware, is to use PWM output to a non-zero-crossing type SSR, rather than the timer controlled output switching. It’s a fairly simple modification to the firmware to support it if you are interested.
in reply to: osPID Firmware UI code #3934Just an update – I have initially completed a rewrite of the osPID firmware for the dual channel PID I am working on. At this point, it only bears a vague resemblance to the osPID firmware I started with. The io.h file is gone, as multiple I/O card support is not needed for my design. The serial communications and dashboard have been almost completely rewritten. The main loop code and other subroutines have also been significantly rewritten to support two PID loops.
Some additional code tweaking may be needed as I continue to rewrite the front-end to support all of the firmware changes, but the firmware is substantially complete, and should work for a stand-alone dual channel PID without profile support. I have published the code to GitHub if anyone is interested, https://github.com/Rhys79/Dual_osPID. You can also find my other projects, as well as the work-in-progress front-end code in my repositories as well.
in reply to: Help getting started with auto tunning #3937The “Relay Output Window” is the frequency at which the PID updates the state of the relay output. The output switching frequency is independent of the PID algorithm loop in the firmware. The lower the window, the more frequently the PID can switch the output relay on or off. There is a hard coded .5s minimum in the firmware. According to Brett “the 0.5 is to protect the relay mainly. but there is also the issue of computation speed. there’s a lot of stuff going on in there, and things start misbehaving if you ask for too much.”
in reply to: SSR Output Switching Rate #3940Not a problem. I’ve spent enough time working on my custom design, I’ve gotten fairly familiar with the hardware and firmware. Let me know how it works out. I don’t personally have a need to switch the output any faster than half second intervals for my design, but it would be nice to know if it is capable of it.
I’ve been in contact with Brett as well, and I asked him about the hard coded limit. His response was “the 0.5 is to protect the relay mainly. but there is also the issue of computation speed. there’s a lot of stuff going on in there, and things start misbehaving if you ask for too much.”
That module would either require access to the RX/TX pins for the hardware serial, which you don’t have on the osPID mainboard, or modifying the firmware to use a software serial library attached to two of the free I/O pins. The firware is easier to modify than the software, but either way, it’s a chore.
in reply to: BGA rework controller #3680I’ve finally started to dig into this project, and I’m making progress. I have the second PID loop and most of the IO.h modifications completed, and the hardware design just needs a little more tweaking and it will be ready. I could still use some help with the onboard dash rewrite though if anyone is willing to help. I’ve started on it, but am stuggling a bit. The frontend looks like it shouldn’t be too difficult either, but I haven’t started on it yet.
in reply to: SSR Output Switching Rate #3938I can’t speak as to whether there is a particular hardware reason for the .5s minimum relay delay, but I can tell you what to modify in the IO.h file to change the minimum.
Look for this section near the top of the output card portion of the IO.h file in the firmware.
void setOutputWindow(double val)
{
unsigned long temp = (unsigned long)(val*1000);
if(temp<500)temp = 500;
outWindowSec = (double)temp/1000;
if(temp!=WindowSize)
{
WindowSize = temp;
}
}The
if(temp<500)temp = 500;statement is what limits the minimum output change interval to .5s. If you change the 500 to 250, you'll get .25s minimum, 100 would be .1s, etc.
I briefly dug through the frontend code, and don't see anything in there that limits the input of the change interval to >= .5s. It looks like if you set it smaller than that, the IO.h code above automatically changes it .5s and then reports that back to the frontend as the current setting during the next update, which happens fairly quickly. As I haven't built my custom design yet, and do not have plans to purchase a stock osPID, I don't have hardware to try making the changes on and verifying though.
Yep, found a bluetooth module on Spark Fun that would work, the RN-42. However, the hardware serial rx/tx pins are direct traces to the USB controller on the main PCB on the existing osPID design, so are not easily accessible. Even with access to the rx/tx pins, a custom daughtercard would need to be designed around the RN-42 module, as it runs on 3.3V and needs a bank of DIP switches for configuration.
So, basically, you’re looking at a major hardware project, but few if any firmware changes are needed.
I like the idea though. I could throw together a daughtercard design pretty quickly based on the RN-42, but I don’t have the necessary tools to assemble it at this time. That would still leave the issue of accessing the hardware rx/tx pins of the atMega on the osPID mainboard though.
It could be done, but would likely require some modifications to the firmware and hardware to add in support for bluetooth serial comms. I’d have to look at the available arduino bluetooth modules and libraries to determine how extensive the modifications would be. My best guess without research would be that it would require a bluetooth serial comm library, some calls to setup the library, and switching out the serial comm commands to call to the bluetooth serial comm library instead of the standard serial I/O library. Shouldn’t be too difficult. On the hardware end, it would be a matter of whether the necessary pins are easily accessible on the osPID hardware.
Alternatively, if there is a bluetooth module that supports two wire serial comm from the tx/rx pins without needing a library, it would only require gaining access to the serial tx/rx signals on the osPID. That might require a little hardware hacking, as if I remember correctly, the tx/rx signals are not broken out to any accessible pads/pins on the main PCB or I/O cards.
I’ll investigate BT modules and reply again in a bit. I’m currently working on a custom firmware/hardware modification that would allow for dual PID loops, so I have some knowledge of how the whole thing works.
in reply to: Additional I/O cards #3678I am currently in the process of building a small CNC mill for milling PCB’s. Once it’s finished, if anyone is interested in either of the I/O cards I’ve designed, or any other custom I/O cards, I would be willing to provide bare PCB’s to those interested at a reasonable cost. I’m working on redoing the board designs to minimize through hole count as I do not have the ability to plate the through holes. It only takes me an hour or so to hammer out a custom PCB design, and the CNC mill i’m building should be able to do one-offs fairly rapidly. I’ll let everyone know when the mill is complete and tested, hopefully in the next week or two, and you can contact me by PM if you want a custom I/O card.
You’re on your own as far as any necessary firmware modifications to support the custom I/O cards though. I’m a hardware guy, I’m not particularly accomplished with software design….
in reply to: Additional I/O cards #3675And as promised, here’s the dual SSR w/ fan speed controller. The fan speed controller should work as long as your using a decent 12V power supply to supply the unit, as I pulled the fan power from VIN.
in reply to: BGA rework controller #3679It’s all good. I think I can handle the backend portion of the modifications, it’s the UI I haven’t had time to dig into yet, and is probably going to need the most work. I’m kinda waiting till they roll the PID shield profiling code into the osPID code before I dig into modifying it too much. The profile functions are pretty important to my plans 🙂
in reply to: Additional I/O cards #3674I about have the dual SSR and fan speed controller output card done also. I’ll post that one later this evening.
The more I dig into this idea, the more i’m thinking I may need to do a complete custom unit to suit my needs. For what I’m wanting to build, having two displays remote to the control board over I2C will reduce the code overhead (only one display library) and make for better mounting. Plus I want to put the USB interface and TC jacks on seperate boards to mount elsewhere, and use surface mount buttons. Your firmware should make for a very good starting point on the software end though. And I’m happy to contribute the I/O card designs I’ve done so far to the cause. Feel free to use them however your want.
in reply to: Additional I/O cards #3672Here’s the schematic and board layout for a dual TC board using Omega K-type TC connectors. Uses the MAX6675 chip, didn’t feel like throwing in a level shifter to make the 3.3V MAX31855 work correctly….
-
AuthorPosts
