No. Encoding to and from JSON is easy. The section of what you're doing that is liable to cause issues is the 'sending over TCP' part. The "official" way to send socket data in Ignition would be the TCP driver, but it's a very leaky abstraction. If you've already got Python socket code, it really isn't a significant uplift to rewrite it to Java's idioms:
Ill look into smoothing this out, but Ill reiterate that it sucks to not be able to do basic network messaging. I realize it's a java problem, but Ignition is a java application so
The key insight is to use Java libraries - you can still write things in Python, so it's not false to say that the scripting you write in Ignition is Python. It is also true that it's a thin veneer, because it's a scripting language - we're not writing Ignition itself in Python, we're writing it in Java.
I understand. Hopefully someday you guys upgrade to cPython or even pypy. I say that knowing it is not trivial.
That's not remotely what I told you. Nothing in Ignition is non-deterministic . I am trying to make sure you understand that calling a script from the script console is not the same as calling a script in an SFC . Those two things are different from one another - but they are not going to be different between themself . If you want to test a script you are executing in an SFC, you absolutely can test isolated pieces of it via the script console provided you understand the differences implied by the different execution scope. The point I was trying to make is that you cannot say "oh, it worked in the script console, therefore it will work in an SFC" in all scenarios - they are different execution scopes, fundamentally.
I didn't suggest calling a script the same environment would produce different results, nor did I infer that. I did not accuse Ignition of being atomically indeterministic, nor do I believe that it is. It is as atomically deterministic as anything running in the JVM can be. I said that I can't trust that "my system will work in production as programmed in Designer", but I suppose I should have said that I can't trust that "my system will work in gateway execution as programmed in my local designer instance. I see them as the same thing, since I can't test script execution in the gateway without running through the rigamarole of building gateway scripts and calling them via message handlers, and I can't build an abstract one of these to handle any method passed to it. I tried, but I suppose the java backend doesn't abstract the same way as normal python.
Those two things are different from one another
The development evironment is different from the production environment. While that is normally true in many instances of software development, this is an "All in One" suite, and I would not expect this to be so aggressively true here.
provided you understand the differences implied by the different execution scope
they are different execution scopes, fundamentally.
I understand this. I am frustrated that I can not trust that they behave similarly. I struggle to understand how you do not already have a reliable method to develop scripts for the gateway scope, considering so many things run there in production. Debugging in the SFC engine is awful and developing there primarily instead of in the relatively well behaved scripting enviornment is a massive pain. The errors are hard to get access to, hard to read, and not usually as helpful as the ones delivered in the Scripting Console.
Can you export a simple, self contained example SFC that is demonstrating this problem?
Possibly, I will look into it. It is quite deep in a larger system, and interacts with a database and a dozen functions.