Who is here? 1 guest(s)
 Print Thread
RobotDyn AC Light Dimmer Module
renatoa
The only thing that comes in my mind at first look is that the zero cross pulses aren't triggered at the right moments.
It can be diagnosed, but requires some code changes.
How is the led on the board activity ? Follows the bulb ?
 
dpecsok

Quote

renatoa wrote:

The only thing that comes in my mind at first look is that the zero cross pulses aren't triggered at the right moments.
It can be diagnosed, but requires some code changes.
How is the led on the board activity ? Follows the bulb ?


So at 0% fan, no LED on. from 1-100% the OT2 LED on the TC4 & a LED on the Robotdyn turn on and stay on.
from 1-50%ish , the light im dimming just flickers a lot like the video i posted earlier. 50% and above its seems like the light gets a little brighter but not gradually, more like it steps up every 20% or so.

what code changes do you suggest to diagnose?
thanks!
 
renatoa
In my fork copy, in the interrupt routine serving ZC detection, added here:
https://github.co...l.cpp#L115

...some code that check if there isn't a parasite triggering of a false zero cross, after the very first, assumed the legit.

byte pinVal = digitalRead(INT_PIN);


   if (pinVal == HIGH) { 

      // false triggering filter
      if ((millis() - lastCross) < 4 ) {
         falseCross = millis() - lastCross;
         return;
      }

      // perform AC monitoring
      lastCross = millis(); // timer0
...


The falseCross variable, can be checked in the main application if you want more detailed diagnose.
It is forbidden to send some output on serial line inside a interrupt routine, that's why any relevant info you want to know have to be stored in variables and checked outside.
 
dpecsok
insert in between line 113 and 114?

...
void ISR_ZCD() {
TCNT1 = 0; // reset timer1 counter
byte pinVal = digitalRead(INT_PIN);
if (pinVal == HIGH) {

// false triggering filter
if ((millis() - lastCross) < 4 ) {
falseCross = millis() - lastCross;
return;
}

// perform AC monitoring
lastCross = millis(); // timer0
...


is this a fix or a way to check the timing? how do i see the results of the diagnosis?
 
renatoa
Stooop, please ! Grin
This code is for a different version of TC4, adapted for ESP family of processors, and posted only as a proof of concept.
Will not work by simply copy-pasted on original Arduino TC4, without a deeper understanding of programming.
For example, surely that first line time reset shouldn't be there... and also there should be a closing } bracket somewhere further in the code, else would not compile, etc...
Is better to wait for the current master of TC4 to add something equivalent for Arduino Uno, thoroughly checked, and committed in the official repository.

This code is both a fix for multiple parasite zero crossings, and also a diagnose method, by checking the falseCross variable.

Attached an image for a better understanding of the issue, which is VERY present in industrial environments, where a lot of heavy loads are started/stopped permanently.
But also in household scenarios, in my home the record was eight such parasite triggering, that forced me to fix them in code.
~~~
renatoa attached the following image:
image_2022-03-20_204259.png
 
renatoa
Before venturing too deep in these assumptions, a simple question: are you using OT2 for the fan control ? I.e. output pin D10?
Because, if reversed, in PAC2 mode the OT1 control is different than OT2 !
 
dpecsok
coding is not my specialty so im waiting till i know for sure from someone who knows better!

yes using PAC2 , OT2 for fan control
robotdyn VVC to OT2
GRD to IO2 GRD
ZC to IO2
PSM to D10

hopefully i have that correct
 
renatoa

Quote

robotdyn VVC to OT2


Vcc connection to OT2 is questionable, because you have no guarantee there is a firm voltage on that pin.
Also, there is no need for this connection, the RobotDyn board designer provided it for other custom applications. Not needed for TC4.
In all my usages of various board models of this design, at least four units that I remember atm, I don't connect the Vcc pin.
Edited by renatoa on 03/21/2022 8:05 AM
 
dpecsok
wow! i think you just solved my issues Grin pulled the VCC to OT2 and its working now with a light. now to try with a motor
 
renatoa
Credits goes to your Vcc <> VVC typo, that catch my attention Grin
 
dpecsok
fyi, i ordered the updated version with the snubber capacitors on the board but instead received an update to the updated version ha! looks like they removed the capacitors again .... size, heatsink, and AC connections are larger; about the size of an SSR now.

trying to add a picture as an attachment but its not working...
 
iPa
As soon I switched from ZCD module bought with the TC4 shield ("ZCDboard") to the ZCD from the Robodyn module ("ZCDrobodyn") I noticed a weird behavior change with the PID control. I made many tests to confirm this difference. For now I don't have any explanation, yes I should get out the oscilloscope...
Any ideas of explanation about this difference, welcome Grin

ZCDboard result:
A bit below the curve at the beginning but reached it soon, maybe need to increase ki
i84.servimg.com/u/f84/20/23/21/77/captur27.png

ZCDrobodyn result:
A lot more oscillations in this case
i84.servimg.com/u/f84/20/23/21/77/captur28.png
 
renatoa
Is the LED on Arduino board lit both cases ? i.e. zcd working, a/c detected.

Looks like you have on-off switching in the second scenario...
 
iPa
The oscilloscope revealed some interesting things:
- The signal polarity is not the same between this 2 boards !!
- If the board is to not connected to VCC the signal is less good drived (so better to connect vcc).

Need to have a look in the code to understand the impact of this reversed polarity, and what is expected.
Maybe @renatoa have you some information about that ?


ZCDboard with vcc
i84.servimg.com/u/f84/20/23/21/77/img_8013.jpg

ZCDboard without vcc
i84.servimg.com/u/f84/20/23/21/77/img_8012.jpg

ZCDrobodyn note the inverted polarity compared to the ZCDboard (with vcc)
i84.servimg.com/u/f84/20/23/21/77/img_8010.jpg

ZCDrobodyn without vcc
i84.servimg.com/u/f84/20/23/21/77/img_8011.jpg

if someone has schematics about this 2 boards I am interested
edit1: I found schematic for the Robotdyn but not for the NZDboard (mine is a verson 6.2)

edit2: Found in the code:
Expected> logic low indicates zero cross
Interrup on falling edge> attachInterrupt( EXT_INT, ISR_ZCD, FALLING );
That means, ZCD interrupt will occurs about 1mS later with ZCDRobotdyn (1/2 period = 10mS = 10%), is that enough to explain the difference behavior, probably. Asap I will test with interrupt on the rising edge with the ZCDRobotdyn.
Edited by iPa on 03/27/2022 10:44 PM
 
renatoa
Could be related to similar processes, as investigated some posts above, starting with #51.

If not intriguing enough, in my TC4ESP fork I changed also the polarity, but for other reasons, without scoping the ZCD signal... Grin

My posts about with/without Vcc pin connected are related to robotdyn board only, never used another make, so can't comment about their behavior, without schematic.
Edited by renatoa on 03/28/2022 1:38 AM
 
iPa
Confirmed!
To use Zero Cross Detection from the Robotdyn AC Dimmer, need to trig on the rising edge. Now my TC4 PID is working as expected (and the Fan drived by the Robotdyn dimmer works very well too).

Note, both board are correctly labeled, ZCDboard (the one bought with the TC4 shield) the output is labeled “/ZC” and the output on the Robotdyn is labeled “ZC”

It should be a good idea to add a define in the code source for to use ZC from the Robotdyn (all boards with positive pulse). Should open a request on github.

How to:
edit phase_ctrl.cpp and replace (line 169) :
attachInterrupt( EXT_INT, ISR_ZCD, FALLING );
by
attachInterrupt( EXT_INT, ISR_ZCD, RISING );
Edited by iPa on 03/29/2022 5:19 AM
 
jake415
Any idea why the robotdyn might modulate power differently depending on the load?
I have the usual setup with robotdyn dimmer, TC4+, and Artisan and when I change use the slider controls on artisan while measuring the current at various levels these are the graphs. (They assume that the artisan sliders relate directly to PAC %)

I'm wondering why the fan current graph is linear while the heater graph is not, and maxes at 50%.
Any ideas? Is it just because the loads are different? Before testing this, I used the heating element at 50% and it burnt out.

For reference this is the fan
https://www.amazo...&psc=1

and heating element
https://www.maste...udes-mica/

Also, as an aside question, what PAC percentage is generally used to control the heater? Seems like it must be pretty low based on this graph.

Thanks
jake415 attached the following images:
heating_element_1.png fan.png

Edited by renatoa on 04/26/2022 3:02 AM
 
renatoa
Maybe you have a MAX_OT1 setting of 50, to limit the heater power to 50%
Because you later stated that...

Quote

... I used the heating element at 50% and it burnt out.

Please explain this... was without airflow, or why burnt...

There is no recommended power percentage, depends on roasting phase and machine build.
For FB and radiant machine the power is pretty linear with the desired temperature, for example if 45% required for 150C, then for 200C you can set the dial and 60%, and be sure will be pretty close without any measurement.
So, if you preheat the machine and charge at half the maximum temperature, then the maximum power during roast could be double compared to minimum power percent. Something like 32 to 64%, just an example.
For this reason, a proportional-on-setpoint control method could be more reliable and accurate than an error based PID control.

For other machine builds, that rely more on heat accumulation, the relationship is different.

All heater percent figures relates to output power percents, not only for PAC, there are three methods to modulate power implemented in TC4.
Ironically, phase angle is the only from these three methods where heater power percent is not directly related output percent, but translated using a non-linear formula.
 
jake415
Just checked and Max_OT1 is set at 100. Still, as shown in the attached graphs the current flow maxed out starting with the artisan slider set to just 50%. That was unexpected since the fan didn't max out until 100.

When the heater burnt out, I was testing the FB machine with the fan on pretty high. It is possible that there was a short or something, but I also suspected the fact that 50% heater control here resulted in max current for the heating element. Can't be sure, but I am weary of using the heating element at max current now (it was 13.4A).

Appreciate learning that temp and power are pretty linear. Also, it's interesting to hear about how PAC related to power percent. By the way, what is an example of set point control method with artisan?
 
renatoa
Control methods are done in TC4 board firmware, via the CONFIG modes in user.h
Artisan just demands: "give me this, give me more/less", not how is this done.

That current value maxing at a certain percent is strange for me to hear... sounds like a delayed phantom zero cross signal is generated...
Please, can you switch the config mode to PAC2, i.e. heater using ICC instead phase angle, and see if it still maxing ?
 
jake415
Looks like it was already on PAC2. Should I try a different one, or change something perhaps? I'm a bit confused because in the comment after CONFIG_PAC2 on my version of the TC4 code, it says "phase angle control on OT1 (heater) and OT2 (fan)," without mention of ICC. I did see that it is mentioned though after the ifdef statement:
#define PHASE_ANGLE_CONTROL // phase angle control for OT2(fan) and ICC control for OT1(heater).

Looks to me like all of the config options beside PWM use ICC for the heater and not PAC, but I'm not sure.
Edited by jake415 on 04/27/2022 4:17 AM
 
renatoa
This is how it looks the last version, assumed official:
https://github.co...user.h#L24

Quote

#define CONFIG_PAC2 // integral cycle control on OT1 (heater) and phase angle control on OT2 (fan); ZCD required on IO2


There is CONFIG_PAC2_IO3HTR that is using fast PWM on IO3 for heater.
Such signal should go into a dedicated PWM driver, not a standard/regular SSR.

Of course, changing the code to use PAC instead ICC is not difficult.

If we clarified you are using ICC for heater, then the 50% maxing could point to the fact half of the sines are skipped, for an unknown reason... @iPa's post #64 above, about reversed polarity of the ZC signal for RobotDyn board could be a hint...
Edited by renatoa on 04/27/2022 6:50 AM
 
jake415
That was really helpful, thank you. I changed the code based on IPA's suggestion in #66 and it fixed the issue. Rising edge helped me to avoid skipping the triggers, and gave me a pretty much linear chart from 0% to 100%.

Attached are two Artisan % vs Current graphs:
One for robotdyn using FALLING zero cross trigger
And the other using RISING zero cross trigger

The falling edge trigger graph shows that current is maxed starting at 50%
The rising edge trigger graph shows a somewhat linear change in current from 0% to 100%!
jake415 attached the following images:
rising_zc.png falling_zc.png
 
progen
I can't thank all of you enough, especially renatoa, who I bugged nonstop in private messages. I finally got mine working. Now the last thing to do is to tweak the PID settings but that'll have to wait because I'm upgrading the heating element to a 6500 - 7000 watt one from 5000+. It's a one week break for some companies in my country because of the Muslim new year. I'm lucky that a bean importer had given me more than 10kg of stale beans for testing when the actual PID tweaking starts.
 
Jump to Forum: