How to debug error messages?

We are getting errors in our model every now and then and don’t know how to debug them. If we use it with the backend API, we sometimes get the error “Sorry, no data to be exported for these parameter settings”. But if we try the parameters locally they work just fine. Also happens on with the model there and then we try with the API and it works.

So basically there is some inconsistency whether or not it works, which are the worst kind of bugs.

How can we go about debugging this? I put in some data outputs at critical points to check the data there, but since I can only get the data outputs using the frontend API I can only debug on making it even harder.

What I noticed is that it could possible be related to a Python component that we use. It’s just 2 lines of code, but sometimes you can get the “Object reference not set to an instance of an object” error and have to restart Rhino for it to work again. So possibly the Python component has failed on some of your servers that’s why it works sometimes with the same set of parameters.

The model in question: ShapeDiver - Online Parametric 3D Configurator

Hi @seltzdesign,

you might find the attached model useful, which reads component error and warning messages from your model and outputs them as data outputs.

Typical reasons for the problem you are facing:

ReadComponentRuntimeMessages.ghx (76.5 KB)

1 Like

That’s cool, thank you!

Any idea when we get data outputs for the backend API?

As for the bug, I removed the Python script now and replaced it with a different logic. It seems to work fine now, making me think that I probably wont use any Python with Shapediver if its that unreliable.

Functionality for data outputs is already there in the geometry backend API. We are about to release an SDK for it (as npm package including types for TypeScript). Let me know if that would help you, and I will send you the link once it’s there for beta testing.

Lots of our users are using Python scripts, i.e. there is no known problem with them. What exactly was going wrong? Do you have a minimal example?

What is the API call for that? Basically the equivalent of api.scene.getData() in the frontend API?

Yeah it surprises me too about the Python component, since we were using it since really early on and it never gave us big problems. But after using the debugging it was definitely that component that was causing it, since there was data going into it, but no data came out of it.

The code was simply:

from ghpythonlib.componentbase import executingcomponent as component
import Grasshopper, GhPython
import System
import Rhino
import rhinoscriptsyntax as rs

class MyComponent(component):
    def RunScript(self, T):
        __author__ = "Corsair One"
        __version__ = "2020.02.13"
        U = []
        for letter in T:
            unicode = ord(letter)
        # return outputs if you have them; here I try it for you:
        return U

We noticed now anyways we don’t need that component, since you can just do it with a GH component instead. But this would sometimes go red and give the “Object reference not set to an instance of an object” error even locally. From the debugging we could tell the same would happen on your servers, but not consistently. I.e. it would fail, then you try again or the same parameters on Shapediver and it would work - probably because it failed on one of the servers, but then the next request would go to a different one.

There is more than one API call going on behind the scenes of the viewer’s api.scene.getData(). It will be easier for you if you use the SDK, will let you know once it’s there next week. Even if you are not working in a JavaScript / node.js environment, the SDK’s source code will be helpful.

About the Python function: Reading the error message you got, my gut feeling is that one of the elements in your input list might be null.

I doubt it because the same input works fine when testing locally and also works fine when testing in a different instance of the viewer. It really seems to be something else.

Looking forward to the SDK, thanks.