tried again in the chdkptp terminal (so with ! before each line) it did not give any error or other feedback and there is no file in the chdkptp folder.
As always, you can debug by checking that each step does the expected thing: That chdku.rlibs:code({'multicam'}) returns a string, and that fsutil.writefile(filename, contents) creates a file. To be more specific:
If you do !return chdku.rlibs:code({'multicam'}) does it print a whole bunch of code?
If you do !fsutil.writefile('test.txt','test') does it create a file named test.txt? If not, what happens if you use a full path to a directory you know you can write to?
1) i am assuming the switch to playback with the sleep would give it enough time to prevent that error. however, the cam still performed the reboot after the exit suggesting it had not ending the cam side script. i guess because during the sleep it does not process a new cmd...
Correct. The multicam script sits in a loop reading messages (in mc.run). When it receives a message, it checks if it starts with a string of non-whitespace characters identifying a command in cmds. If so, it calls it, and no more messages are processed until the command function returns.
If no matching command is found, it writes a status message with message text 'unknown'.
If the PC sends messages before the command completes, they are queued (in the camera side C code) until the script calls read_usb_msg again.
3) cam side already includes a 12 sec sleep after moving to play and before actual reboot. is that explicitly enough? or should it also wait for a message 'disconnect'.
12 sec should be plenty, you just need time for mc:cmd to complete sending to all cameras and the disconnect to complete, which should be a small fraction of the a second with only a few cameras.
included another file, with the new code it only made one attempt to reboot before a halt:
I don't understand what this refers to.
making the disconnect work leads to a fault with init_sync()
WARNING: init_sync_single_send /home/me/chdkptp/lua/multicam.lua:559: attempt to perform arithmetic on a boolean value (local 'rt0')
So
init_sync_cam sends a 'tick' message, waits for a response, passes the result to init_sync_single, passing the message status value (which should be the result of the 'tick' command in rt0
init_sync_single then calls init_sync_single_send with the same value as rt0.
The error says rt0 was a boolean when should be a number, presumably in the line
local expect = rt0 + diff
That implies that either the response to the 'tick' command was a boolean, or there was somehow a different, stale message waiting. I don't see an obvious way either of these would happen in the code you posted, but a first step to debugging would be see what's in the message, for example by printing it like
function mc:init_sync_cam(lcon,count)
local t0=ticktime.get()
lcon:write_msg('tick')
local msg=lcon:wait_msg({
mtype='user',
msubtype='table',
munserialize=true,
})
-- added
printf('%d: %s\n',lcon.mc_id,util.serialize(msg))
self:init_sync_single(lcon,t0,msg.status,count)
end
The message from 'tick' should look like:
1: {
status=81670,
cmd="tick"
}
Note that it includes the name of the command the message is a response to, specifically to aid debugging mixed up messages
