DSP Robotics Support

MyCo wrote:New FS versions are always backward compatible, so you can always load older FS versions schematics. But once you save the schematics in newer FS versions you might not be able to load them in older FS version. It's like it always was. Nothing has changed there.

That's good! Thanks for clarifying.

Cheers

Spogg

Btw i must say its nice that myco helps in this. Hes deep coder. i have seen hes work

Now sometimes a Flowstone window appears: "A required resource was unavailable." => also in compiled EXE's...

and while changing something in schematic and recovery file was written - hangup and crash randomly...

any news about next beta release?


P.S.: It's a very big project

Hey MyCo,

may I bring this to your attention? I experience this in 3.0.6, but maybe it can be solved in 3.0.9? Easy setup to see the issue:

Create a module with an mgui prim and a view output. Connect the view output (on the higher layer) with a RubyEdit, create a draw method and put these two lines inside the method


Now select the view module:

The report is as expected.

Now de-select the view module:

As you can see, a wrong grid size is reported.

Furthermore, consecutive clicks on the schematic's free space (like you would to de-select) show that the grid size is reported as 8.0 for a fraction of a second, but then falls back to the odd value, which means, there are at least two redraws triggered (for one click on the schematic's free space), the second one overwriting the (correct) first one.

Interresting! I can reproduce it in 3.0.9 and there seems to be something wrong with gridStep and one redraw. I'll have a look.

@Walter: That looks like a Windows Message to me, maybe something from DirectSound? We'll have to somehow reproduce it, to find the cause for the message.

Not sure what the plan for the next release is. Maybe we just release 3.0.9 with all the fixes for the problems that were reported here. Not sure if a Beta2 makes sense.

I have another bug.
when creating a streamboolout in DSP,
with a streamin, the streamin will become a streamboolin (the connector type).

I have gone back to 81 for now

that's already fixed

MyCo wrote:Not sure what the plan for the next release is. Maybe we just release 3.0.9 with all the fixes for the problems that were reported here. Not sure if a Beta2 makes sense.

A beta makes sense, when there are a lot of testers. That there aren't many people testing must be discouraging for you. I don't know why others don't spend time on it. I would test it intensively, if it wouldn't be made so difficult. Especially that I can't test it sandboxed in a way. I am no friend of fiddling around with the registry. Just make it a public beta (maybe with a timebomb or something) that is self-contained. If one can just extract a zip and run it, that's helping a lot. I have quite some projects going on, where I can't and am not willing to switch versions in between. So, being able to test it without influencing the current install would be the only way for me.

Tronic wrote:

Tronic wrote:I would like to take the opportunity to discuss the Client and Server primitives,
which seem to have problems to send buffer larger than 256 bytes,
and also the Client have problems with port binding, it does not receive any data,
with various external servers I have tested.

So if there was the possibility to set the receiving port on the Client primitive,
instead of always having a random port, it would be better,

while for the Server primitive, it should be able to set its own IP,
and also be able to set the max buffer input/output byte for both primitive.

News on this?

I often find myself in the situation of working with multiple ethernet cards,
so it would be useful to specify the IP address with which to have the connection,
without this possibility, it occasional connects to any ethernet card, based on how it is configured in the system,
for example, preferred almost always the one with static IP, but this is not guaranteed if multiple adapters are configured with static or dynamic IP.

sorry to re-up this....

it would also be nice to have a Ruby input/output connector, so not more forced communication in HEX format.
And a setting to decide to use a specific Ethernet card, it would be very useful.

+1 what tulamide said. I did some testing of the new mem stuff but finally gave up in frustration because of the constant crashes. In particular, when using the analyzer (which I use a lot) it would crash more often than not. If you can fix it or at least explain how crahes can be avoided, that would be awsome.