I created an instructable on how to use a single remote control to connect 1 to many Canon cameras (and some other brands). The remote is powered and operated by the Duet board so you can now send g-codes at layer change to take an image (and do much more).

This remote covers some 20 plus Canon Cameras and some other brands. I'm sure the principal applies to other remotes as well.

You can find the instructable here: https://www.instructables.com/id/Duet-Controlled-Timelapse-Video-Using-Camera-Remot/

@dc42 Thx, M84 U followed by G92 U0 does the trick

I'm already using the 4th Axis U. U (P4) runs the motor that switches the XYZ belts to operate the bed. Watching the video may clarify that a bit better https://youtu.be/L9pTHMi5SP8.

The bed is a "virtual" 5th axis. it is moved by XY and Z (P0, P1, P2) when the 4th endstop is triggered X Y and Z need to stop.

The other issue I run into is that trying to use the E0 or E1 endstop can not be managed by M574 (only 1.16 and below). these seem to be only usable as Z-probes now (using M558)

It would be nice to be able to assign a gcode file to specific endstop (TriggeredE1.g) in which I can do what I need. Kinda like homeu.g is there for homing axis U.

So for the many tries with different values, it was always the same story. As M42 P60 S255 was executed (at random layers changes) the filament sensor would error out. I can only conclude a "power spike/drop" when powering a relay (3v) to trigger the camera remote was causing this issue.

I've now redesigned my remote setup and eliminated the relay. The remote is now directly powered via pin CS5 (P60). It now correctly finishes my print and I tested the sensor for stall and all seems to be working.

I wonder though if it would be possible to check for multiple consecutive before completely stopping the print. Once the power fluctuation is over all works well again.

case TypeLaserMessageTypeError:
lastErrorCode = val & 0x00FF;
sensorError = true;
break;

I'm good for now. Thanks for responding.

At the faire I would have had it switch to wifi hotspot and at home it would have gone back to connecting to my home wifi, so it was more than on/off (if that's a clue)

I might try upgrading that but it'd be another band-aid. This problem has been popping up for years now and, like with me, the last time "it just went away" and was no longer pursued but it keeps re-occurring. That's the part that makes it frustrating.

This has come up before but I've never seen a satisfying solution to this. For a long time I was uploading my files at 600Kibs plus speeds. I took my Printer to a faire and when I hooked it up again (after MRRF was canceled). my upload speeds went down to 40Kibs again. I've tried different routers in different locations (NetGear and Asus). I've tried changing channels with no results.

M122 P104 S200 gives me 2Mbytes/sec so the SD card isn't the problem either. Has anything else come up since all the previous upload issue posts have been idled? Thx

Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later
Firmware Version: 2.04RC1 (2019-07-14b1)
WiFi Server Version: 1.23
Web Interface Version: 1.22.5

@zapta said in Filament Sensor plus timelapse issue:
It was powered by the E0 end stop. I don't know (yet) where the Duet 3.3v rails starts and ends. Only the signal came from the CS5 pin.

@zapta Sorry, this goes beyond my expertise. This is the relay I used The relay I'm using is this guy: https://www.amazon.com/gp/product/B01M0E6SQM

I did not add anything additional to this. I did just read about the power spike. One would think that when you buy a unit like this it's built in. Then again...

@t3p3tony I have no scientific equipment to validate this but I did go through some 12 attempts of the same benchy with different parameters and all failed as the exact point in the macro (different layers), right after

M42 P60 S255

The relay I'm using is this guy: https://www.amazon.com/gp/product/B01M0E6SQM

VCC and GND on relay came from E1 end stop, signal came from pin CS5

So for the many tries with different values, it was always the same story. As M42 P60 S255 was executed (at random layers changes) the filament sensor would error out. I can only conclude a "power spike/drop" when powering a relay (3v) to trigger the camera remote was causing this issue.

I've now redesigned my remote setup and eliminated the relay. The remote is now directly powered via pin CS5 (P60). It now correctly finishes my print and I tested the sensor for stall and all seems to be working.

I wonder though if it would be possible to check for multiple consecutive before completely stopping the print. Once the power fluctuation is over all works well again.

case TypeLaserMessageTypeError:
lastErrorCode = val & 0x00FF;
sensorError = true;
break;

I'm good for now. Thanks for responding.

@t3p3tony the cable is long (about 3 meters) but the problem only occurs when I run the snapshot code. The error must occur between:

;turn on shutter and wait 800ms
M42 P60 S255
G4 P800

;turn off remote
M42 P60 S0

as I find the M42 P60 S0 never executed (camera stuck taking pictures).

The relay controlling the camera is powered by E1 end stop (could it cause a power drop next door?).
The cable to the sensor is separated from all other cables running to Smart Effector.

I think I'm running into a problem with my Duet Filament Sensor Laser combined with taking images at every layer change.

following is my image taking code (executed at every layer):
G60 S1
G91
G1 Z40 F9000
G90
G1 X0 Y0 F9000

;turn on shutter and wait 800ms
M42 P60 S255
G4 P800

;turn off remote
M42 P60 S0
;based on bad lighting give time for picture to be taken.
G4 P2000

;return to last stored position
G1 R1 X0 Y0 Z0 F3600

Basically I'm taking a 3 second break every layer and I think this messes up the Filament sensor and averages of moved filament. I get filament sensor failed errors.

Is there anyway to avoid this?

current M591: M591 D0 P5 C3 R90:120 E6.0 A0 S1

I tried playing with the A parameter switching from A1 to A0 and changing parameter E from e3 to e6

Also, error says: Extruder 0 reports sensor not working

What triggers that error (it's different from the jam/filament out error)

@dc42 Thx, M84 U followed by G92 U0 does the trick

@dc42 Okay found the solution (or I should say the cause to the problem). My printer, the crazy Delta one with a moveable bed, uses a 4th axis defined as U. Since it's defined as U it becomes part of the homing process. The problem is that U is used only a few times a year (mostly at shows) but runs hot every time after it homes.

Because of that every print of mine starts with M84 U (to shut it down). This the cause of the problem.

All code has DoFileMacro(gb, PAUSE_G, true); made conditional with AllAxesAreHomed()

because of M84 U they are not and thus pause.g is not executed.

I'll have to do something else to stop U from overheating.