Qidi Tech 1 - Replicator 1 clone

[Stwert]

It is not and my scope is half a house away so I cannot test but I suspect there is no PWM being fed or if it is it is at full throttle because S1-S255 there is absolutely no difference in fan speed. Already hard defeating the printing mechanism to test this since there is only on and off via the front panel for the fan and apparently in the firmware too. I have Stwert intrigued he is going to test it as well but he was in a print.

Seriously, this works on other Mightyboards with a real Sailfish so that can only mean Qidi effed something up in the firmware and let me tell you a gale force wind from that blower even PLA would not stick. I mean I only ever used 100% on my I3 when doing a bridge and anything over 40% was too much. Now on a standard fan, not a cage blower, 100% is fine.

7.8 needs to be removed and the real 7.7 installed but not a soul has done it that I could find. Going up from a non SF version to the current version of SF at the time but never trying to go to the real SF.

How this has never been found out means most people only take it for granted OR are using only ABS but it is seriously unacceptable to have a 100% fan for even PLA.

Now I did do some digging and if you send the printer the fan command without the S it is at full speed so I wonder if they effed up the parser section so it ignores the S portion of it?

I really can't stand this compiled code and wish this was gcode so some solid testing could be done because I do not know if it is the Qidi or is it S3D? I immediately ran to the software given on the SD card but no fan commands on either.

Ok, so not that I'd need to but I can confirm what DA is saying, with the Qidi it's all or nothing no matter what you try for the cooling fan.

I've been doing some digging on the matter and it seems we need two things for it to work. A compatible Sailfish and it seems we're running the unreleased beta (well alpha really) version of it. The last update of which was 8 days ago. But digging through the code on GitHub (though not too extensively, I've only had an hours sleep) it seems we should have PWM control regardless of which 7.8 alpha Qidi has chosen to use. Although there should be an option available on the LCD in the utility's for the cooling fan as well and we're missing that, so I don't know what Qidi is up to.

So other than that the only other possible suspects I can think of is that we're missing the FET on the motherboard to regulate the speed.
I can't rip my printer apart until the wife gets out of bed to go to her work but I'm going to have a look when she does.
Or Qidi have removed the option in the firmware, in which case flashing the latest 7.8 should rectify the matter.

I've reached out to Qidi for clarification to find out which alpha they have used and just what they have to say about the lack of speed control. Though I doubt there will be a reply on a Sunday.

Ohhhhh, I do enjoy a mystery, ha.

[DarkAlchemist]

Ok, so not that I'd need to but I can confirm what DA is saying, with the Qidi it's all or nothing no matter what you try for the cooling fan.

I've been doing some digging on the matter and it seems we need two things for it to work. A compatible Sailfish and it seems we're running the unreleased beta (well alpha really) version of it. The last update of which was 8 days ago. But digging through the code on GitHub (though not too extensively, I've only had an hours sleep) it seems we should have PWM control regardless of which 7.8 alpha Qidi has chosen to use. Although there should be an option available on the LCD in the utility's for the cooling fan as well and we're missing that, so I don't know what Qidi is up to.

So other than that the only other possible suspects I can think of is that we're missing the FET on the motherboard to regulate the speed.
I can't rip my printer apart until the wife gets out of bed to go to her work but I'm going to have a look when she does.
Or Qidi have removed the option in the firmware, in which case flashing the latest 7.8 should rectify the matter.

I've reached out to Qidi for clarification to find out which alpha they have used and just what they have to say about the lack of speed control. Though I doubt there will be a reply on a Sunday.

Ohhhhh, I do enjoy a mystery, ha.

Emily is there on a Sunday but she will say she has to ask the "engineer" who has about as much brain power as does some moss on a dead log.

I firmly believe that a lot of the functionality in SF was removed by them because their product lacks a lot of things and/or they are too afraid of allowing the masses to have that much control but a lack of fan speed control takes the cake. Unless there is a missing FET (I think you will see there isn't unless I skipped over it though at the time I wasn't concerned about this) then they borked the code with their dodgy programming skills. It has already been shown, numerous times, they do NOT know wth they are doing and are just playing it by ear.


edit: This is not that easy to look through as Marlin but here is for the fan -

#if defined(COOLING_FAN_PWM)
if ( fan_pwm_enable ) {
// fan_pwm_counter is uint8_t
// we expect it to wrap such that 255 + 1 ==> 0
if ( ++fan_pwm_counter == 0 )
fan_pwm_counter = 256 - (1 << FAN_PWM_BITS);
EX_FAN.setValue(fan_pwm_counter <= fan_pwm_bottom_count);
}
#endif

I wonder if they have that toggled off?

I may have found the issue -

#if defined(COOLING_FAN_PWM)

void Motherboard::setExtra(bool on) {
uint16_t fan_pwm; // Will be multiplying 8 bits by 100(decimal)

// Disable any fan PWM handling in Timer 5
fan_pwm_enable = false;

if ( !on ) {
EXTRA_FET.setValue(false);
return;
}

// See what the PWM setting is -- may have been changed
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
fan_pwm = (uint16_t)eeprom::getEeprom8(eeprom_offsets::COOLI NG_FAN_DUTY_CYCLE,
COOLING_FAN_DUTY_CYCLE_DEFAULT);
}

// Don't bother with PWM handling if the PWM is >= 100
// Just turn the fan on full tilt
if ( fan_pwm >= 100 ) {
EXTRA_FET.setValue(true);
return;
}

// Fan is to be turned on AND we are doing PWM
// We start the bottom count at 255 - 64 and then wrap
fan_pwm_enable = true;
fan_pwm_bottom_count = (255 - (1 << FAN_PWM_BITS)) +
(int)(0.5 + ((uint16_t)(1 << FAN_PWM_BITS) * fan_pwm) / 100.0);
}

Something tells me they have it messed up in the internal eeprom due to this line -

// See what the PWM setting is -- may have been changed
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
fan_pwm = (uint16_t)eeprom::getEeprom8(eeprom_offsets::COOLI NG_FAN_DUTY_CYCLE,
COOLING_FAN_DUTY_CYCLE_DEFAULT);
}

I bet a dollar to a donut they stupidly set that to 255, or it is gibberish and was not set therefor faking the code to think it is >=100. This is the part of the eeprom we can't see and are always told not to mess with else brick city.

[Stwert]

Emily is there on a Sunday but she will say she has to ask the "engineer" who has about as much brain power as does some moss on a dead log.

I firmly believe that a lot of the functionality in SF was removed by them because their product lacks a lot of things and/or they are too afraid of allowing the masses to have that much control but a lack of fan speed control takes the cake. Unless there is a missing FET (I think you will see there isn't unless I skipped over it though at the time I wasn't concerned about this) then they borked the code with their dodgy programming skills. It has already been shown, numerous times, they do NOT know wth they are doing and are just playing it by ear.


edit: This is not that easy to look through as Marlin but here is for the fan -
I wonder if they have that toggled off?

Yeah, I've just had a look at the motherboard and the FET is there and the connections are all as they should be, so that rules that out, it's definitely a software thing. I'd love to be able to see their source code, not that that'll happen.

[DarkAlchemist]

Yeah, I've just had a look at the motherboard and the FET is there and the connections are all as they should be, so that rules that out, it's definitely a software thing. I'd love to be able to see their source code, not that that'll happen.

See my edits above.

After reading the docs on SF 7.7 it seems we can write, and read, the eeprom to and from the SD card so if we knew where these two bytes were we could check the number that is there via a hex editor and if >= 100 we could change it.

What we are after, and probably change, is eeprom_offsets::COOLI NG_FAN_DUTY_CYCLE

edit: Lookee what I found (btw, this is the first time I ever downloaded, or saw, SF code so this is a learning experience compared to Marlin).

//Fan PWM level (0 - 100)
//$BEGIN_ENTRY
//$type:B $constraints:l,0,100 $tooltip:Set a blower strength (duty cycle) to use for the print cooling fan when it is activated by the print commands. Select a value between 0% (off) and 100% (on full). For example, if your fan is too strong, you may want to set this value to 50 so that the fan operates at 50% strength. If set this value to 0, then the cooling fan will not activate at all when the print commands request it to.
const static uint16_t COOLING_FAN_DUTY_CYCLE = 0x0F63;
#define COOLING_FAN_DUTY_CYCLE_DEFAULT 100

It would appear that this 4k file it will write the byte to look at would be at 0x0F63. What is throwing me is that it sounds like the duty cycle has to be set in the eeprom but that can't be right since the M command has a speed setting.

Yep, looking at this eeprom file everything is where it should be and what is there but a ton of 0xFF AND right at 0x0F63 is 0x64 which is 100 in decimal. So, PWM is never used.

Thing is if COOLING_FAN_PWM is not defined when compiled then the fan will always be full force and it will take a recompile and an upload to get rid of their 7.8 to get the fan PWM back.

Ahhh, crud I think I am chasing a red herring because in the Menu.cc there is this

#if defined(COOLING_FAN_PWM)
CoolingFanPwmScreen coolingFanPwmScreen;
#endif

Since we never see this then this probably means it was never defined so Qidi turned it off on purpose.