DSP Robotics Support

support wrote:Tronic - we prefer the idea of adding dedicated primitives. Using Ruby to process frames was too slow to be of any practical use anyway. So this is the direction we'd like to go in.

This is exactly what I wanted, in fact what I have ALWAYS wanted. A prim that can be used to call a function from a DLL directly from FS. Now that's true power and flexibility!

The new Ruby implementation needed to happen exactly the way it is... I understand that it has limitations in its current form, but at least the plugs run stable now. As for running custom DLLs.. That should be done directly from FS and not go through a third interface like Ruby or anything else. Ruby in this case is playing an intermediary to more powerful languages like C++, so in essence by calling from Ruby you are still going to be limited by what it can do, and someone mentioned arrays in ruby. That's a prime example of limitations.

I'd like to see Ruby stay as it is, but would like to see an additional prim added that allows us to call our own external DLL's. Maybe this is an opportunity to use COM? On the plus side, it would open up a whole different set of ideas and interfaces. In the industrial world, on the production floor, there are many opportunities where I could see COM being more than useful. It would open up FS in a very direct way to AB PLC's, GE FANUC controllers, and many, many, more COM compliant software.
On the negative side, I'm not sure what the lifespan of COM is anymore with this new MS Metro programming?

Just my two cents

Anyways, congrats on a fantastic update Malc, all this stuff needed to happen!

IMO if you want better interface capabilities go with OPCUA (unified architecture) versus COM (old OPC). Most of the newer controllers and SCADA systems I see coming out now supports OPC.

OPC UA also comes with nice APIs..

In case anyone wonders where it would be useful ---> structures and other complex data types over network messaging

like this stuff.. http://www.commsvr.com/UAModelDesigner/Index.aspx

fixstuff555 wrote:IMO if you want better interface capabilities go with OPCUA (unified architecture) versus COM (old OPC). Most of the newer controllers and SCADA systems I see coming out now supports OPC.

OPC UA also comes with nice APIs..

In case anyone wonders where it would be useful ---> structures and other complex data types over network messaging

like this stuff.. http://www.commsvr.com/UAModelDesigner/Index.aspx

Yep.. agreed
That would serve the "industrial" needs of FS while at the same time giving extra needed capabilities to the VST side of things. However, I did not find any pre-made starting point frameworks for it.

It took me about a year to learn all the "secrets" of primitives. What can teach one that had nothing to do with this software? 7 days? ...hm...

Version 3.0.3 crashes on me when I'm scrolling thru the toolbox every time.. I reverted back to 3.0.2 and NO problems with the toolbox.... Any ideas ?? -J

I had the same problem and this is a soluluzione:
you get to your modules folder from Menu [Toolbox] -> Open Folder Modules ...
move all your modules in other folder,
and add them gradually to find the one that contains a External Device Primitive.

In the previous version is loaded without problems
in the last all modules that contain External Device Primitive, blocking the toolbox.

Yes i can confirm

I have had this problem with the last couple of flowstone updates, for me it only affects a couple of my user categories i have created in the toolbox! clicking on them crashes flowstone for me!

the easiest way of fixing it is return to your old working version and save out the contents of your user categories by placing your third party modules or user creations into a workspace and save the fsm, install the new version and load up your saved fsm, re-create your user categories and add the modules from the fsm.

no more crashes for me i am pleased to say! seems to have fixed the issue in the past for a few others around here!

i have now saved about ten fsm's that contain my user library and i update these regularly with any new bits and bobs i or others have created, so that i can turn to them after any new updates! basically just a backup! i also regularly back up my modules to dvd disks just in case of a catastrophic event with my pc

hope that helps!

Thanks guys I'll give it a go... also another weird issue since version 3.0.0 is I back up my modules folders including the tags etc. then I do a windows re-install and load my user modules back into the AppData/Romming folder and the performance of scrolling thru the toolbox degrades 50% or More. this happens everytime I add my user modules that way. The only way to fix it is to rebuild the toolbox using a FSM or a synthmaker project and drag everything back into the toolbox.. Big pain in the butt.. how bout we put the toolbox back the way it was in synthmaker had no trouble at all with SM... but that's just a thought LOL

It sounds like some sort of indexing issue.. ?

support wrote:billv - yes, that looks like the default for the Maths tag. Let us know if you get any clues as to what might be causing the tags to get dropped.

Tronic - we prefer the idea of adding dedicated primitives. Using Ruby to process frames was too slow to be of any practical use anyway. So this is the direction we'd like to go in.

Regarding the issues you've reported, I didn't quite understand fully. Are you saying you get crashes dragging from the toolbox in 3.0.3? Can you email with more details as to what components cause a crash.

Are you also saying you're seeing higher cpu? Could you send an example?

@Support...
Yeh its happened again. First time in 3.03.
Here's sequence of events.
1. X11 open, dragged the whole "tempo module" from inside matrix into toolbox.
(note: this one module is ridiculously large..205,849+ parts)
2.Shut down/Resart FS...toolbox takes too long to load.....reason is all parts in toolbox have been
duplicated again......Shut down/Resart FS again...duplications are gone...but..
My "maths"/"System" and "String" folders are empty.
Hope this helps...
Ps.
Managed to re-build that module with same visuals and behavior for 150,000 parts less.
so will be trying to avoid this "large module" into toolbox bug thing.....
if you guys need a "particular" test done..let me know