Update to 85.2 Unresponsive Issues

After about 1hr running the server it would no longer show my printers or even the dashboard anymore. The log shows the following error msg numerous times: 

2017-07-08 13:13:06: LUA error calling sendEvent:...iles (x86)\Repetier-Server\modules\server\lua\render.lua:100: attempt to index a nil value (local 'manager')

I have several printers sharing the same gcodes, thanks for the new feature btw! The server is running on windows 10.

Any help in remedying this would be much appreciated. 


  • At a first look I'd say uploading from a printer not being master storage is not working correctly. I have to test this. Th eother question is if that makes so much trouble that a print stops.
  • Ok, have tested uploading on target printer and the one using target an dit worked without issues. Only thing was that it got rendered twice, which I have fixed for next release, but that does not cause the error.

    Can you show the complete log (dropbox/googledrive) and tell me when the problem occured.  Your error would come if no model manager exists for a file to update. Since every printer has one I wonder how you got the error. One thing might be if it tries to render a model in the "old" storage, but uploading new files should not trigger that problem.

    Did you do anything else while printing like preparing new models that could lead to the problem? And also quite important did the printer continue to print with ui not responding? These are different threads so it might work or not depending on what exactly happened.
  • So to your last point the printers continue printing fine so I guess that means it is the UI thread. After doing some testing the error shows up after trying to add a new print job to the queue and after every attempt the error shows 4 times. With the new update I erased my old 'models' folder and added all the prints again so it shouldn't be a collection of old and new model files. The 'LUA error calling sendEvent:' error may not even be whats causing the server to hang because it worked fine for aprox. 2 days and during that time it printed over 200 prints across all the printers. The whole time it gave the error message but still continued to print fine. I will PM you the server log and continue to try and troubleshoot whats happening when it freezes.  
  • Ok, I could reproduce the LUA error. It is related to the shared storage calling an event for all shared printers but only one will work. Next version will silently return in that case as one of the following calls will do the correct work. But as far as I can see this does not cause any harm as the error gets catched and in these cases there should be done nothing anyway.

    You can also fix the error just to be sure it is not causing the ui hang. In INSTALL_DIR/modules/server/lua/render.lua replace around line 98 the function with this version:

    M.gcodeInfoUpdatedHandler = function(event, printer, data)
    local manager = printer:printjobManagerFromFile(data.modelPath)
    -- since it gets called for all sharing printer it might happen that only one has a manager
    if manager == nil then
    local name = manager:decodeNamePart(data.modelPath)
    local id = manager:decodeIdPart(data.modelPath)
    local imageFile = manager:encodeName(id, name .. "_l","png")
    if printer.slug == manager.printer.slug and not rs.pathExists(imageFile) then
    rs.dispatchJob("rendering.render",{id=id, image=imageFile, layer=manager:encodeName(id,name,"layer"),slug=printer.slug,list=manager.managerType},1000)

    In windows that directory is not writeable so you need to copy, edit and copy back. Then restart server.

    You said the hang happens after these messages, which is correct as these come after the file is uploaded and analysed. Can you be more precise as my tests just start the print leaving ui intact (I guess like with your first 200 prints). Sometimes I see this in your log:

    2017-07-08 13:12:10: finish job C:\ProgramData\Repetier-Server\printer\WhitePrinter\jobs/00000008_Mermaid Bra-3.u
    2017-07-08 13:12:10: Closing websocket for missing ping
    2017-07-08 13:12:17: Closing websocket for missing ping
    2017-07-08 13:12:27: Closing websocket for missing ping

    Which indicates in deed a disconnect but normally it will reconnect directly afterwards. So do you have any errors in javascript console if you check it (in chrome right click and investigate or however this is called in your language then to console).

    But without knowing how to reproduce or more informations I can not find it. I guess something has changed for you so it started happening, just now we need to know what the difference to the first 200 prints is.
Sign In or Register to comment.