Problem with Point Buss Status in Allen Bradley 1734-AENT module - plc

I'm having a problem with a 1734-AENT module, the red light of the Point Buss Status is blinking red, and the value goes to cero in a little fragment of time, know how to fix this??
To fix the Point Bus Status of the module

Related

Conveyor agent crossing allowed gap

Update: link to simplified model with replicated error added
In simulation model of conveyor technology, we are using a conveyor object type roller and we are moving our custom agents of transporter type by convey block always to the next position on a conveyor (imagine this as a exit or entry point on conveyor). It happens in some random seeds, that our agents cross allowed gap and Anylogic shows following error.
It always happens when some agent enters convey block, but the error occurs on two other transporters, when the one behind crosses the gap. - THIS IS NO LONGER TRUE. Today it happened when there was no agent entering convey block. We did not find any way to ignore this error or to find a workaround. Anyone has any ideas how to resolve it ? Picture of actual situation added, pink conveyors are breaking gap, and error pops up. We also found out that gap is broken also before, but error does not pop up.
link to simple mode file with replicated error: https://cloud.anylogic.com/model/ceafcc2a-9a05-4bb9-a56f-a1c018698b16?mode=SETTINGS&tab=GENERAL

Fastest way to determine line of sight on a grid

I am improving a video game of mine where I currently have the problem that NPCs can shoot through walls. In order to fix this issue, I have decided to completely re-do my work regarding ground combat.
I use a tight grid for finding paths from any point A to B. I store my grid as an image-like structure and use Jump Point Search for the pathfinding itself. My goal is to find a location that is as far away from the enemy as possible (limited by the firearms's range) that also has a direct line of sight to the enemy.
In my latest approach, I determined all nodes in my grid that are within weapon range and that are connected to the enemy's location (colored in green in the image below). The final missing part is filtering these points so that only the points with a valid line of sight remain.
I can also detect the border lines (colored in blue) very fast. I could check for every node, if a line from this node to the enemy would intersect any border line. If that is not the case, I have clear line of sight. However, I assume this to be neither fast nor the optimal solution.
Do you have any ideas or suggestions? I am glad for any hint!
I visualized the grid in the following image to give you an idea of what I am talking about. If a character would stand in the lower right green area, he could not shoot the enemy in the upper left area because of missing line of sight.

Deploying to Hololens 2

I opened up a unity project and simply put a cube on the scene view. I then got it to deploy in Visual Studio 2019 without any errors.
When I viewed it in Hololens 2, it shows up as a blank image with no error message to be found anywhere.
Any idea as to what could be happening that would cause this?
Thank you
Since I can't add a comment yet, here's an answer that should be seen as an addition to Hernando - MSFT's answer.
Additionally to the scaling of the cube, it makes sense to position it reasonably. As already mentioned, one unit corresponds to one meter.
In the Inspectorview of the cube, Z is the distance to the camera and X and Y are the horizontal and vertical offsets.
Reasonable values for the mentioned position are X/Y/Z equal to 0/0/0.5 for example. Then the cube should be in front of you after starting the application.
Have you manipulated the cube's Scale property after adding the cube into your scene?
In MR spatial coordinate system, 1 unit = 1 meter, and the default Scale property of the new cube is "1, 1, 1". This means that the cube will be too large to completely block your view, so you can only see a blank.
We recommend that you try to manipulate the cube's Scale property to "0.1, 0.1, 0.1" for testing, if you see any different behavior, please let me know.
I think it can be
your box is too large and near the camera
or the Clear Flags of Camera is Skybox. If so, you can try to use DefaultHololens2ConfiurationProfile

RTX Recursive Rendering

I am trying to achieve nice looking reflections with the unity RTX capabilities. Under the volume component, I have turned on recursive rendering:
I then set my material's rendering pass to be raytracing. The setting only allows for a ray length of 50 and I appear to get weird artefacts:
Does anyone have an idea what I'm doing wrong? What is that weird line and how do I blend it? How do I get rid of the black when an intersection exceeds the ray's length of 50 units?
Cheers!
For the first issue, I found a fix. It has to do with the light cluster: https://docs.unity3d.com/Packages/com.unity.render-pipelines.high-definition#7.1/manual/Ray-Tracing-Light-Cluster.html

MakeCode EV3 motor invert not working with motor.xx.tank

I'm using the beta MakeCode for Mindstorms EV3 at https://makecode.mindstorms.com/ and I've found an issue that might be a bug.
I'm using the Motor Invert block to reverse the direction of my motors.
When I check the result on the simulator, I see the direction of the motors change, but when I download the .uf2 file to the EV3, the motor's direction of rotation doesn't change. I've tried putting the "inverted" setting to "on" and "off" and I see that affecting the simulation but not on the physical robot.
I tried changing the EV3 output ports but that didn't help.
Here is the Javascript version of my code.
brick.buttonUp.onEvent(ButtonEvent.Pressed, function () {
brick.setStatusLight(StatusLight.Green)
motors.largeB.setInverted(true)
motors.largeC.setInverted(true)
motors.largeBC.tank(50, 50)
sensors.touch4.pauseUntil(ButtonEvent.Pressed)
motors.stopAll()
})
brick.setStatusLight(StatusLight.GreenFlash)
Is there a problem with how I'm reversing the direction of rotation?
As a test I tried replacing the motors.xxxx.tank with motors.xxxx.run and then it does reverse the direction of rotation both on the simulator and the physical robot.
motors.largeB.run(50)
motors.largeC.run(50)
Thanks for reporting this bug.
It does indeed look like the tank block doesn't respect the inverted state of the motors.
For now, you can use:
motors.largeBC.tank(-50, -50)
to reverse the motors using the tank block.
I've filed a bug on our end to track this issue. Thanks!