Love the addition of custom scripts. Since this is based on a chain of events, I would suppose one would have to know what comes before and after it (script wise) so it will integrate properly. Not just any script will work in any configuration. And what works in one place will not necessarily work in another place. Anyway, what I'm saying is that this particular component may require a bit more attention to explanation in the tutorial.

I know this is a WIP, but I thought I'd take the occasion of this update to mention a couple of things I have seen about the operation of the Scratch window.

First, there is no vertical autospacing that occurs when a component is inserted between two other components.

Second, the components cannot be pushed below the bottom of the window or the right side. This makes it impossible to add components beyond those points, limiting the total number of components allowed. I see that if you shrink the window into where the components are, scroll bars will appear so I guess it is meant to be able to scroll both ways. As it stands now, however, there seems to be no way to go beyond those boundaries. It might be helpful if, when pushing a component to the bottom or right side, the scroll bars appear and the whole image shifts in the appropriate direction.

My apologies if I am premature in all these issues and you were going to address them in due course.

Can you post a screen shot of what you're seeing?

Nothing that you've described is a bug or an issue, if I'm understanding the post correctly.

1. you can move elements around the screen to make room for new elements. Sliding an element between two other elements will cause you to move those other elements.

2. the boundary of the screen is restricted so children and new users learning to program do not accidentally lose elements that are hidden with scroll bars.

Correct. I'm not saying they are bugs as such, just limitations. I see now that the boundary restrictions are purposeful, so that explains that.

The autospacing (vertical expansion) that I am talking about is more of a convenience than anything else. Just that I thought it would be nice if the space between elements would automatically open up (vertically) when a new element was moved in between two elements already in place. This, as opposed to how it is now in which the lower one (and every one under it) has to be moved down manually to make room for a new control placed above it. I thought it would be good if those controls would automatically move down to make room for the new component. Likewise, everything automatically move up if a control is removed.

Since this is for beginners, I figure there is going to be a lot of insertions and removal of components as users are experimenting with how things work. That means a lot of shuffling of other components down when something is added to a column. Having the components move back up when something is removed is, of course, not as big as deal as things moving down when one is inserted. It would just help keep things tidy.

Speaking of tidiness. I wonder if it would also be good if the elements snapped into place (at least initially) so that the lines between them were nice and vertical. I guess I just like things to line up easily. In a way I suppose that would be akin to the auto-arrange option in ARC for getting controls to line up. So making a "snap to" option in this could be good.

Just suggestions.

Updated the version to .28 because this one now includes the MPU9150 update as mentioned in the first post

Sorry to say this DJ, but the MPU9150 is still not giving data of any value from the compass (and yes, I did the calibration routine, several times). At least now it appears to be giving degrees, the values are between 0 and 354 (maybe 360 but I have never seen it above 354 yet this evening).

Regardless of orientation, it always reads somewhere in the 200's, then will occasionally jump for a second or two down to 14 or so, up into the 300s, and then settle back in the mid 200's. It definitely detects movement, because it is fairly stable when still, and it seems to know which direction it is moving, because the value will raise or lower depending on which direction I turn it, but then it jumps wildly and seems to have no basis in reality.... Turning it 180 degrees, it will jump back to around its initial value as if I had turned it 360 degrees. If that was at least consistent, it would be useable, but it jumps wildly between other values on its way there.

I have tried it in every orientation - flat with the circuit board up, flat with it down, vertical with the plug on top, vertical with the plug on the bottom, sideways. No difference, and it is connected to a bare EZ-B with no servo motors or any other magnetic sources nearby.

I have tried it on two different EZ-Bs tonight, and used different I2C ports on both of them.

In the same location where I am testing the compass on my phone works perfectly, even if I bring some servos fairly close to it. The compass x, y, and z variables fluctuate between positive and negative numbers with no apparent basis in reality.

Also, the temperature is now reading between -2000 and -4200 celsius and fluctuating wildly.

Do you think I just got a bad circuit or do you need to go back to the code again?

Alan

Perhaps you have metal around it? Yes, the temp has not been adjusted yet - waiting on additional info about decoding the data correctly.

@Alan... I will try mine later tonight when I finish work...

@DJ, no metal or magnets nearby. Compass in phone works. I'll test tonight compared to a needle compass too.

Alan

Hi Guys, Any more on the compass?

Ron

DJ. Either you or Jeremie in one of the other threads about the compass issues mentioned that the sensor device is being redesigned. Are you testing with the old one (that was sold through Brookstone) or one of the new ones?

If it works with the new one, I will wait for its release and include one in my new order. I have almost enough EZ-Credit to cover it anyway, and the accelerometer/gyroscope at least works on this one, so it will have a use, just not the one I bought it for.

Alan

Hey Alan,

We are testing with one of the Brookstone sensors. At the moment we are revisiting the older code while we finish up development on the new sensor. As you can see, ARC is getting some new additions as a result.

OK. As usual, if there is anything I can do to help test. Logs, debug builds, whatever. I am curious if Richard R's and Andyroid's sensors work better than mine with this build. If they do, I'll assume mine is bad and wait until they are shipping again, but if not, I am here to help....

Alan

Hi Alan I will test mine tomorrow morning and let you know how I make out.

Ron R

I have added comments from tonight's testing to your thread here: https://synthiam.com/Community/Questions/8867

Makes more sense for the issue to have its own thread than to keep talking about it in the release notes thread.

Some progress, but more weirdness too.

Alan